Frozen Date objects?

Mark S. Miller erights at
Thu Jul 18 14:54:36 PDT 2013

+1. We should do something along these lines. I especially agree with "Having
[X] depend on an implicit global [Y] is madness" for any X and Y.

On Thu, Jul 18, 2013 at 10:01 AM, Dean Landolt <dean at> wrote:

> 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