On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg < [email protected]> wrote:
> > On Apr 15, 2013, at 5:43 , Dean Landolt wrote: > > > On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg < > [email protected]> wrote: > > > >> 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. > > No, Date instances are in UTC - read the spec. > https://mail.mozilla.org/pipermail/es-discuss/2013-March/028928.html > I believe you're misunderstanding me. > The time zone of the host system is, as you say, global state. Confusing > instance data and global state has real hazards in many areas of software > development. > You're suggesting that implicit, hidden global state is the right thing? Can you think of another example in the language of this kind of ambient state? If there is I bet it'd look like a bug. > > 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. > > So which one are you proposing: having "Date instances ... own their > timezone" or "slap the system timezone as a symbol on Date.prototype and > correct all locale-specific date methods to respect this symbol"? These are > not the same. > As you've said, the underlying "value" of a date is UTC. But there are a bunch of locale-specific methods that depend on a global timezone state. I'm simply suggesting that instead of this global state it would be better if these locale-specific methods resolved the appropriate timezone instead by using an explicit property (using prototypal inheritance for a sane default). Again, this timezone is not part of the "value" of a date, and would not be preserved on copy. It simply codifies something that's already happening, allowing it to be controlled in an idiomatic way. > > If you want to alter the timezone used for locale methods on a specific > instance just set this property. > > Changing the property would affect all instances that have Date.prototype > as their prototype, not just "a specific instance". Sure, if you set the property on Date.prototype, but I didn't say to do that. Perhaps code will clear things up -- here's an example of using my proposal and its effects: Date.prototype.localeTimezone; // 'America/New_York' var d = new Date('2013-04-15Z'); // Sun Apr 14 2013 20:00:00 GMT-0400 (EDT) +d; // 1365984000000 d.localeTimezone = 'America/Los_Angeles'; // 'America/Los_Angeles' d; // Sun Apr 14 2013 20:00:00 GMT-0700 (PDT) +d; // 1365984000000 var e = new Date(d); // Sun Apr 14 2013 20:00:00 GMT-0400 (EDT) Date.prototype.localeTimezone = 'America/Los_Angeles'; e; // Sun Apr 14 2013 20:00:00 GMT-0700 (PDT) Only locale-specific methods are affected -- we're just making the global lookup for timezone into a prototypal one. I can't imagine anything more idiomatic.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
