Plotting issues with daylight savings time

[eddified]

In my timezone (America/Denver), when plotting times during the day that daylight savings time went into effect in the United States, plotted points are off by 1 hour.

The following example plots March 8th @ 11pm, and March 9th @ 12am.

Expected: these points should plot as 1 hour apart.
Actual: these points are plotting as the same point in time, as 12am on March 9th.

Code:

var data = [
  {
    x: ['2015-03-08 23:00:00', '2015-03-09 00:00:00'],
    y: [1, 3],
    type: 'scatter'
  }
];

Plotly.newPlot('myDiv', data);

Details: in my cursory tests, all points between March 8th @ 3am (inclusive) and March 9th @ 12 am (exclusive) are plotted 1 hour off, due to confusion with Daylight Savings time.

Tested against plotly.js v1.3.1 (minified)

I suggest that any fix for this should also be tested against points during the day when daylight savings time ended in the U.S., which is November 1, 2015

[etpinard]

Bug confirmed. Thanks for the bug report.

[eddified]

May I suggest using the excellent Moment.js library http://momentjs.com/ to fix this? This would also make it easier to support timezones (by including moment-timezone js) , see http://community.plot.ly/t/timezone-on-plotlyjs/26

I know it is undesirable to introduce a dependency on another library, but... I can dream, can't I? ;)

I can't use plotly for my project until I can figure out how to allow display in arbitrary timezones. If you make plotly extendable (so that I can add some hooks to use moment-timezone), that would work splendidly.

[mdtusz]

This seems to be happening because of this line.

When the date is initially computed with new Date(2015, 2, 8), it returns a date object - in my case in Montreal, GMT-0500, for you in Colorado, it should be GMT-0700. This is because the time change does not occur until 2015-03-08 02:00:00. Once we have this, we are then adding 23 hours worth of milliseconds.

When new Date(2015, 2, 9) is computed (GMT-0400 in Montreal, or GMT-0600 in Colorado ) this time is "correct".

Javascript's Date computes values based on the machine time zone, so unless you are in a region without daylight savings (e.g. Greenwich), your times will be "adjusted".

Play around in your console:

> new Date('2015-03-08 02:00:00')
> new Date('2015-03-08 03:00:00')

As you'll see, they both return the time at 03:00:00.

This is a pretty simple fix though. @alexcjohnson, would you be fine with us culling the code for dateTime2ms in dates.js and replace it with a simple call to Date? This will allow for more flexibility of date strings (namely, timezones) and the only thing we'll lose is the ability to use 2 digit years (which probably isn't a horrible thing, and we can write a shim to fix it if need be as well).

[alexcjohnson]

This issue is a bit of a hydra. It's also connected, for example, to the bug (not sure if it's listed somewhere...) that if you set an explicit range for a date axis, save the plot, and someone in a different timezone opens the plot they will see the wrong range.

Rather than (or at least before) supporting timezones, which seems to me like it would add a whole bunch of complexity but wouldn't get much use, I feel like it would be much better to switch our date/time handling to UTC. To do this in the most nearly backward-compatible way for plot.ly users we should do this at the same time as changing axis ranges from linearized numbers to data values (and annotation positions - I think everything else, including shape positions, is already stored as data values). And THAT issue is tricky for ensuring backward compatibility on log axes, which is where I stopped thinking about it and moved onto other things 🙈

There's also the issue that our auto ticks are at weird hours (13:00 instead of 12:00 for example) in the summer months; that would get trivially solved by switching to UTC.

The biggest disadvantage I see of using UTC is for people who care about hourly data around the time changes. But for a lot of other use cases it's nice if every day renders as 24 hours long rather than occasionally being 23 or 25 hours. Timezones could certainly be added in explicitly later for the people that care about this.

I'm not sure what the simple Date call would do to our date handling, but I would be worried about it - for example, as I recall there are no specs for what dates the browser should be able to parse and how, and I believe I've seen some fairly significant browser differences that we really don't want to introduce into our plots.

[sidhoda]

For anyone else hitting this issue, here's a workaround using UTC timestamp X-axis values and overriding the tick and hover text displayed using array tickmode and hoverinfo: "text+y":

https://jsfiddle.net/sidhoda/180x2e2g/

Not the most elegant solution but it at least displays the correct local times.

[larsonmpdx]

most time-using applications long ago settled on UTC as the only sensible time format, except for presenting things to the user at the very end. plot data should be required to be in UTC for simplicity

[xirzec]

I would appreciate an option in the axis to have it be UTC based - while it would be spiffy to have plotly magically convert everything into local time, right now it's just making my dataset look weird since all of our daily data points show up at 16:00 the day before and it seems a bit silly that I should have to first pre-process all of my dates to pretend to be in the current timezone.

[eddified]

Dygraphs v1.1.1 provides "good" tick marks with date/time data such that if you pass it a set of date/time data points (not just dates) that span these "weird" Daylight Savings Time days (that is, days which contain 23 or 25 hours), it will still put the tick marks intelligently at the start and end of each day. It compensates by leaving less space between the tick marks for the 23 hour days, and more space between the tick marks for 25 hour days.

It also does this without trying to work with arbitrary timezones, (it works for UTC and local time). However, it's easily hackable to provide your own timezone, and it still provides "good" tick marks. (My 'hack' which integrates moment-timezone js with Dygraphs to show data in an arbitrary timezone is here: http://stackoverflow.com/questions/24196183/dygraph-showing-dates-in-an-arbitrary-timezone )

In short, if you could provide the algorithm to choose "good" tick marks in a timezone-agnostic way, and provide a callback we can use to add support for arbitrary timezones, I'd be very happy. (I'd like to migrate from dygraphs to plotly but this is preventing me from doing so.)

[eddified]

@sidhoda's answer comes pretty close, it just doesn't provide the "good" tick mark algorithm. But I can get that algorithm from the Dygraph library, and I may do that...