OK, I've started delving deeper into this. The problem was that TimeStep
isn't timezone aware. So roundTimeDown
and roundTimeUp
round to the nearest threshold in UTC. Which isn't what is needed here - we need to round to the nearest threshold in display time zone.
One idea would be to adjust the timestamps by the time zone offset - but this gets very complicated very fast due to DST. In fact, TimeChart itself doesn't really do the right thing when it comes to DST - it doesn't display double-hours and missing-hours when the DST is toggled.
So, yes, it's a bit messed up. But there is a simple way out, which is perhaps a little less efficient. What matters is that each event generates one value for every display unit, and you can ensure that by simply taking the start timestamp and incrementing. Like this: http://jsfiddle.net/zmq5rt27/6/
For multiple events however this will result in a sub-optimal data object where there will be multiple points for every display unit (one point per event, unless they happen to line up precisely). However this too is OK, because TimeChart will just happily aggregate these values and show the right thing.
And a final optimization that should almost entirely negate this overheard would be to filter by the requested from/to values and just return the data for the visible part. Just don't forget to set the correct dataLimitFrom
and dataLimitTo
values which include the entire available data set. And remember that the endpoints (to
and dataLimitTo
) are exclusive, so they should be bigger than the biggest available value.
The only real issue might be that once a year when DST is toggled there are double time values. That is, 3AM happens twice in one day. The above code will dutifully generate one timestamp per requested interval, so during this one hour things will be doubled. Can you live with that?