Le 15 avr. 2013 à 14:43, Dean Landolt <[email protected]> a écrit :
> > > > On Sun, Apr 14, 2013 at 10: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. > > > 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 > [email protected] > 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. —Claude
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
