Fixing timezone issues with the x-Axis dateTicker #912
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've noticed dygraphs was choking on my charts for some time now, but assumed it had something to do with my own data at the time. But I decided to investigate recently and discovered a bug in the
getDateAxis
function.Based on the (automatically chosen)
granularity
, this function steps through the timestamps accordingly to generate the desired x-axis labels. It does so by creating an array with fields that correspond to year, month, day, etc. It uses that to instance a new Date object for each step.However, the
start_date
that is used for comparison is instaced usingnew Date(start_time)
. If you look at the documentation for theDate
constructor closely, these do not produce the same date:So, this function was called with any timezone different than
UTC
, it resulted the loop being called a lot more than it needed, based on thegranularity.step
and timezone difference. In my case.And the reason nobody noticed this until now is because in the last
Dygraphs
released, millisecond granularity was introduced with #893. Up until then, those extra calls only accounted for a few thousand more based on the number of seconds between UTC and localtime. However, with millisecond accuracy, those calls quickly account for millions more, which results in pretty significant lag.And when
Dygraphs
is called with an emptyfile
,start_date
isnew Date(0)
andstart_date.getTime() === 0
, buttick_date
is basicallynew Date(1969, 11, 31, 21, 0, 0, 0)
andtick_date.getTime() === -3600000
(for my timezone).This PR fixes the issue by using UTC accessors to instantiate
tick_date
, which makes it equal to howstart_date
is instanced.