Frozen Date objects?

Brendan Eich brendan at
Wed Jul 17 20:35:10 PDT 2013

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

Mark wants to do this from JS, not from under the hood (usually via C++) 
using VM internal APIs.

>   you don't need to do anything to Date instances - all you need to do is change the implementation of LocalTZA and DaylightSavingTA.

Those are spec-internal helper functions, analogous to 
hidden-from-JS-"user-code" VM internal functions.

> 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.

Right. People travel. DST happens (too early these days in the US!) and 


More information about the es-discuss mailing list