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

Claude Pache claude.pache at gmail.com
Mon Apr 15 03:53:24 PDT 2013


Le 15 avr. 2013 à 09:27, Sorin Mocanu <sorinmocanu at google.com> a écrit :

> Hi Norbert,
> 
> Sorry for not having better explained my suggestion.
> `var date = Date.withTimeZone("America/Los_Angeles", 2013, 3, 9, 15, 11, 0);` would create a Date object with a local time for "America/Los_Angeles", regardless of my computer's timezone.

Although I guess what you mean, I think it doesn't make sense to say "... create a Date object with a local time ...", since a Date object does not represent a local time. Alternatively, I may have misunderstood your formulation.

Anyway, it would be clearer if you say the following:
* `Date.withTimeZone()` would create a Date object **from** a local time, etc.; and
* a Date object would internally hold not only a given point in time (more precisely, a millisecond offset relative to 1970-01-01 00:00:00 UTC), but also an optional timezone information which will be used for d.getHours() et al.

— Claude

> The difference is that calls to date.getHours would not be local to the system timezone, but to the timezone passed in the constructor. Hence getHours would return 15 since the "local time" is not my computer's time, but America/Los_Angeles.
> 
> If you feel that this is a stretch of the current contract AND adding arguments to existing methods is discouraged, would you rather suggest to add new methods which are timezone aware?
> Such as:
> `getTzHours("America/Los_Angeles")`
> 
> Then for `var d = new Date(1365627600000)` ran on a computer with the local timezone of Europe/Zurich the following would be true:
> d.getHours() == 23; // The local time in CEST
> d.getUTCHours() == 21; // The UTC time
> d.getTzHours("America/Los_Angeles") == 14 // The time in PDT
> 
> Thanks!
> 
> Sorin Mocanu, Software Engineer
> Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland | 8002 Zurich | Identifikationsnummer: CH-020.4.028.116-1
> 
> 
> On Sun, Apr 14, 2013 at 7: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. Also, I'm not sure what to make of the second example - how is the time zone used in the interpretation of the time value, which should be in UTC? And why does getHours return 15, seven hours behind UTC, when you're in Switzerland?
> 
> Norbert
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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


More information about the es-discuss mailing list