On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg < [email protected]> wrote:
> > 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. > *Or* the spec could redefine those functions to use an instance property lookup which defines the appropriate timezone. I'd suggested this several months back, and partly for this reason (it's also a much needed feature, and more idiomatically javascripty). Having Dates depend on an implicit global timezone is madness. Using a prototype property would allow Date objects to have their timezone explicitly set or modified, and they'd be possible to freeze. `Date.prototype.timezone` (or whatever it would be called) could then float with the system's timezone (or be explicitly set and/or frozen too). Oh, and this could be cleanly polyfilled to make dates and timezones suck less today. I still can't think of any downsides.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
