Frozen Date objects?

Dean Landolt dean at
Thu Jul 18 10:01:32 PDT 2013

On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg <
ecmascript at> wrote:

> On Jul 17, 2013, at 20:35 , Brendan Eich <brendan at> wrote:
> > 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list