On Jul 17, 2013, at 17:27 , Mark S. Miller <erights at google.com> 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

On Jul 17, 2013, at 17:27 , Mark S. Miller <erights at google.com> 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