Le 15 avr. 2013 à 09:27, Sorin Mocanu <[email protected]> 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
> <[email protected]> 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 <[email protected]>
> > 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
