plotly.js: Shapes and annotations do not handle Date objects or strings with time zones

At the moment (version 1.25.1), data traces can handle Date objects, which will then be displayed with what seems to be the browser’s timezone settings. For example, date = new Date("2017-03-30T00:00:00.000Z") used on the X-axis in a trace, with a browser in the UTC+1 timezone will be displayed as “Mar 30, 2017, 01:00”, which is indeed correct.

However, that same date object cannot be used for x0/x1 in a shape on the same object.

When using date.toISOString() instead (both for data and shapes), the timezone indicator (e.g. Z) at the end of the string is ignored and the string is considered to be within the local time zone.

Here is a jsfiddle to demonstrate the problem: https://jsfiddle.net/tkhmx8Le/

image

Effectively, the problem is two-fold (and might lead to two separate issues):

  • It would be good if shapes and annotations also supported date objects.
  • ISO-8601 date parsing should take into account the Z (or generally +xxxx or +xx:xx) timezone indicator before building its internal UTC representation. This is certainly related to #1003 (and subsequent work).

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 4
  • Comments: 19 (7 by maintainers)

Most upvoted comments

Any progress on this? It seems like some sort of time zone support (or at least the ability to specify a time format function or string) is still badly needed.

Any news?

I’d just like to add that the direction of using date strings over Date objects seems terribly inefficient. Obviously, Plotly has to convert these into Date objects somewhere, so that just adds overhead. But worse, we have apps that do large amounts of Date-related processing on the same data that drives the charts. If I have to constantly convert these to Dates, do something, then convert them back to strings to hand to Plotly, that’s a ton of wasted time. Especially if you’re dealing with hundreds of thousands of data points (which we are).

I’ve just looked into it a bit further. I think it’s not so much that Plotly handles date/times as UTC. Rather, it seems to discard all potential timezone information altogether and assume there’s only one timezone, making it the “unique” timezone.

For example, "2017-03-30 05:00:00-0800" and "2017-03-30 14:00:00+0100" should be the same moment in time. Yet, they’re interpreted as “2017-03-30 05:00” and “2017-03-30 14:00” (in what’s effectively the unique timezone).

image

Essentially, it’s not handling timezones at all, which creates oddities for DST changes (like last week-end in the UK): https://jsfiddle.net/tkhmx8Le/3/ (This is skipping a point, for otherwise valid representations.)

image