On Jul 17, 2013, at 20:35 , Brendan Eich <[email protected]> wrote:
> Norbert Lindenberg wrote: >> 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, > > 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
