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.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=796523
Right. People travel. DST happens (too early these days in the US!) and
ends.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
