On Jul 17, 2013, at 17:27 , Mark S. Miller <[email protected]> wrote:
> This is unfortunate. It does answer Anne's question though, in an unpleasant > way: Date instances cannot be immutable; they can be at best readonly. > Despite lack of any authorization to track the user's position, Date > instances make visible their machine's mutable current position, as coarsened > to the timezone. > > Just as a Date instance snapshots the time when it was created, I think it > should also snapshot the timezone where it was created. Then it would be > possible to contemplate immutable Date instances. Only the Date constructor > should give the ability to sense changes to time and place, not the instances > it makes. Virtualizing the Date constructor (replacing it with a faux Date > constructor) should be adequate to create illusory paths through time and > space, without needing to wrap all the instances it creates with faux Date > instances. If you want to lock down the behavior of getTimezoneOffset, or create illusory behavior, you don't need to do anything to Date instances - all you need to do is change the implementation of LocalTZA and DaylightSavingTA. On the other hand, the behavior in Firefox was made more dynamic under the assumption that users prefer to see date and time information in their current time zone, not in the time zone they were in when they launched their browser. https://bugzilla.mozilla.org/show_bug.cgi?id=796523 Norbert _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
