Time zone offsets for any time zone, possible change to Date functionality (i18n)

Claude Pache claude.pache at gmail.com
Mon Apr 15 06:33:24 PDT 2013

Le 15 avr. 2013 à 14:43, Dean Landolt <dean at deanlandolt.com> a écrit :

> On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> wrote:
> On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
> > I'll add this as a second option to the strawman.
> >
> >
> > 2013/4/9 Sorin Mocanu <sorinmocanu at google.com>
> > Thank you Nebojša.
> > How about if the [timezone] parameter would only be passed at the construction of the Date object? That would (perhaps) allow a user to centralize timezone validation as well.
> >
> > For example:
> > var date = Date.withTimeZone("America/Los_Angeles", 2013, 3, 9, 15, 11, 0);
> > var date = Date.withTimeZone("America/Los_Angeles", 1365545496000);
> > date.getHours(); // 15
> > date.getUTCHours(); // 22
> > Sorin Mocanu, Software Engineer
> > Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland | 8002 Zurich
> I'm afraid this would be quite confusing. Many people believe already that Date instances are in some local time zone, which they aren't, and this would lead even more astray.
> Of course Date instances are in some local timezone -- the timezone of the host system. This data isn't explicitly carried along with each date -- instead it's just more implicit global state. But it's naive and even hazardous to pretend a Date instance has no timezone component -- to say this with a strait face would requiring removing the locale-specific date methods. This is what is leading so many astray. Further, I've found that changing the host timezone can wreak havoc on this implicit state in some environments. I couldn't find anything in the spec about expected behavior but there are subtle but real hazards lurking here.
> Previously I'd suggested that Date instances should just own their timezone. Make explicit what's already there implicitly -- slap the system timezone as a symbol on Date.prototype and correct all locale-specific date methods to respect this symbol instead of some hidden global state. Of course this has no impact on a date's underlying value, just on the behavior of its locale methods. If you want to alter the timezone used for locale methods on a specific instance just set this property. You can get a Date constructor pinned to a specific timezone through subclassing. Weak implementations lacking proper tz support would freeze this property on fresh dates.
> All the while nothing about Date objects and their methods would change -- it would be fully backward compatible. With a little more thought it could be made polyfillable (perhaps it doesn't need to be a symbol at all, if a suitable name can be found that is unlikely to collide with existing libs). What's not to like? More specifically, in what way is the current state of affairs better?
> [snipped the rest]
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Hi Dean,

What would be the behaviour of the following steps:

(1) store a Date object `d` locally using IndexedDB;
(2) change the timezone of the operating system, and maybe restart the browser;
(3) retrieve the date `d` stored in step 1.

In what timezone will be the retrieved date? and in what timezone should it be?

I have not try the experiment, but my educated guess is that (1) the value of`d.getUTCHours()` would remain invariant and (2) the value of `d.getHours()` would vary according to the change operated in step (2). In other words, `getHours`, `setHours`, etc. do have (unfortunately) an implicit parameter, which is the timezone provided by the system, but that parameter is not part of the `Date` instance.

Now, do you propose that `d` should hold its timezone information, so that it would remain in the old timezone, but `dCloned = new Date(d)` would be in the new timezone? *That* seems hazardous to me.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130415/f72eb639/attachment.html>

More information about the es-discuss mailing list