Fixing timezone issues with the x-Axis dateTicker

[saboya]

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 using new Date(start_time). If you look at the documentation for the Date constructor closely, these do not produce the same date:

Note: Where Date is called as a constructor with more than one argument, the specifed arguments represent local time. If UTC is desired, use new Date(Date.UTC(...)) with the same arguments.

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 the granularity.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 empty file, start_date is new Date(0) and start_date.getTime() === 0, but tick_date is basically new Date(1969, 11, 31, 21, 0, 0, 0) and tick_date.getTime() === -3600000 (for my timezone).

This PR fixes the issue by using UTC accessors to instantiate tick_date, which makes it equal to how start_date is instanced.

[coveralls]

Coverage remained the same at 90.195% when pulling 212c452 on saboya:wrong-date-ticks into 6611837 on danvk:master.