mergeDateTime

[sjd201]

I was thinking this morning about the zipDate function. The code that uses it feels like it is a bit more complicated than it needs to be and it was a bit hard for the students to pick up. I was thinking it might be better to create an alternative function that takes a list of events and a time unit and returns another list of events where the new events are merged versions of the old events that are in or cover each unit.

For instance,

mergeDateTime(Events, "day")

would take the original Events list and create a new event list in which each event corresponds to a day. The StartDateTimeLocal would be set to 00:01 of the day and the EndDateTimeLocal would be set to 24:00 of the same day. Any fields that were unique across the period would be copied to the new event.

By default, fields that occurred more than once would have list values added. However, we could also include an aggregator dictionary as a parameter that mapped field names to aggregator functions. The aggregator dictionary might map a field like Accelerometry Count to the sum function, the Temperature field to the mean function, Message field to the join function and the Latitude field to the median function. (Need to think about how to compose the aggregator functions so we can override the choice of an aggregator function for one field type without having to redefine all of the others).

The other question is which events will be added to each new event. Events for which the StartDateTimeLocal is after the start of the new event and before the end of the new event should be included. Events that start before the StartDateTimeLocal of the new event and end after should also be included by default (although we might want to have a parameter controlling this behavior). Events that straddle either the StartDateTimeLocal of the new event or the EndDateTimeTimeLocal of the new event but don't completely encompass it are a bit ambiguous. Maybe don't include them by default but have a parameter that allows them to be added.