On Sun, Apr 14, 2013 at 10: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.
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
