DateFormatter and timezone

[dvdplm]

The docs for the DateFormatter (https://developers.google.com/chart/interactive/docs/reference#dateformatter) is vague on what values are accepted for the timeZone option:

• are fractional values accepted? If yes, in what form?
• how does the library handle DST?

Thanks

[dlaliberte]

Hi David,

First the easy part: the timeZone option should support fractional values, since some time zones use half-hour shifts.

The question about DST is interesting, and I am not entirely sure what the correct answer is. It is also difficult to test unless we can effectively teleport the test machine to various points in space and time.

Generally, the formatting of dates should work similar to how the default format is generated, but just with more variations possible. So DST should be accounted for the same either way. If not, let us know.

Google Charts internally uses the goog.i18n.DateTimeFormat to do the formatting. See https://google.github.io/closure-library/api/goog.i18n.DateTimeFormat.html

More specifically, here is a possibly relevant question and answers: http://stackoverflow.com/questions/16317807/does-javascript-date-tolocalestring-account-for-dst

It appears that, at least for JavaScript's toLocaleString, the DST that applies will be determined by the location of the machine doing the computation (i.e. each user with their own machine will be in a different location). So it is not the DST for whatever timezone you might choose to do the formatting.

There are also two sets of timezone names (rather than the numbers), with and without DST applied. e.g. PST and PDT, for standard and daylight-savings versions of the Pacific timezone. That would suggest that, when you specify a number, you get that timeshift, regardless of DST for your local machine.

How DST applies also depends on the date, since the rules changed: http://stackoverflow.com/questions/16946002/javascript-time-zone-is-wrong-for-past-daylight-saving-time-transition-rules

All this may be different in different browsers as well, since the standards appear to be confusing enough to have left the details not specified clearly enough, or people missed the details.

If anyone knows more about this, please speak up. Hope this helps, at least to understand more about the question, if not the answer.

On Wed, Jan 25, 2017 at 8:11 AM, David notifications@github.com wrote:

The docs for the DateFormatter (https://developers.google. com/chart/interactive/docs/reference#dateformatter) is vague on what values are accepted for the timeZone option:

• are fractional values accepted? If yes, in what form?
• how does the library handle DST?

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/google-visualization-issues/issues/2444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAizDdTgFhw2HKmslHxVDL7qdS8ULGg4ks5rV0odgaJpZM4Ltd9D .

-- Daniel LaLiberte https://plus.google.com/100631381223468223275?prsrc=2 dlaliberte@Google.com dlaliberte@google.com 5CC, Cambridge MA

[dvdplm]

Hi David,

First the easy part: the timeZone option should support fractional values, since some time zones use half-hour shifts.

…even 15min shifts. It's complicated. ;)

The question about DST is interesting, and I am not entirely sure what the correct answer is.

What some other libs do is they require a datetime value to calculate the correct offset, e.g. momentjs do this: moment.tz("Europe/Berlin").offset(Date.now()), which will return the offset (in minutes, as per the above) corrected wrt to DST. This is, imo, the best approach.

It appears that, at least for JavaScript's toLocaleString, the DST that applies will be determined by the location of the machine doing the computation (i.e. each user with their own machine will be in a different location). So it is not the DST for whatever timezone you might choose to do the formatting.

Yeah, this is problematic. E.g. the US switches to DST two weeks earlier than the rest of the world (and to add to the mess, this change came to be during the Bush years, so fairly recently which in turn means that US DST switch date for, say 1996, is different than for 2014), so if you rely on the local browser to figure out if DST applies or not, you'll be an hour off for weeks twice every year. Again, the solution I like best is to require a date with the input to figure out what applies where.

For my particular case I need to render charts – Timelines – with user-selectable timezone, so relying on the browser is not an option.

The ideal solution would be to specify the time zone as "Africa/Algiers" along with a pattern and let the library figure out what conversions need to be, given the current dataTable.

Thanks!

[dlaliberte]

You might want to push on the Google Closure folks to address this by supporting an offset date in the formatter. Then we can use it. Since Google Closure is open source, you might even offer a change.

[dvdplm]

Google Closure folks

Ok, I'll see what they say. Can you point me to the piece of Closure that the charts lib pulls in for this capability?

[dlaliberte]

The goog.i18n.DateTimeFormat is the place to look, I believe: https://google.github.io/closure-library/api/goog.i18n.DateTimeFormat.html