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. 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 <
ecmascr...@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 <sorinmoc...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
