Frozen Date objects?

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Thu Jul 18 09:44:06 PDT 2013


On Jul 17, 2013, at 20:35 , Brendan Eich <brendan at mozilla.com> wrote:

> Norbert Lindenberg wrote:
>> 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,
> 
> Mark wants to do this from JS, not from under the hood (usually via C++) using VM internal APIs.

Sorry, I missed that bit.

In that case, you'd have to replace the Date function and all Date methods that depend on the local time zone: Date as a function; the Date constructor for 2 or more arguments; parse; toString & friends; getFullYear, getMonth, and their non-UTC friends; getTimezoneOffset, setMilliseconds, setSeconds, and their non-UTC friends. That's a lot more work, but it still doesn't affect Date instances directly.

Norbert



More information about the es-discuss mailing list