Frozen Date objects?

Jonas Sicking jonas at
Sun Jul 21 23:05:07 PDT 2013

On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg
<ecmascript at> wrote:
> On Jul 17, 2013, at 16:59 , Jonas Sicking <jonas at> wrote:
>> On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie <bbenvie at> wrote:
>>> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
>>>> On Jul 17, 2013, at 16:51 , Brandon Benvie <bbenvie at> wrote:
>>>>> On 7/17/2013 4:42 PM, Brandon Benvie wrote:
>>>>>> On 7/17/2013 4:36 PM, Jonas Sicking wrote:
>>>>>>> Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
>>>>>>> handle Date objects representing timezones other than the user's
>>>>>>> current timezone?
>>>>>> What happens if the timezone changes between the creation of two Date
>>>>>> objects, such as for daylight savings or the user changes their system
>>>>>> timezone?
>>>>> Having just tested this, it is possible in SM to get two Dates that
>>>>> report different values from getTimezoneOffset.
>>>> How?
>>>> Norbert
>>> Create a Date object, change the system timezone, create a second Date
>>> object. They reflect the timezone at time of Date object creation, not a
>>> static one.
>> That doesn't reflect what I'm seeing. I see the timezone of all Date
>> objects changing whenever the timezone is update. Existing instances
>> are also changed.
> Seeing getTimezoneOffset change for *all* Date objects is what I expect because none of them actually *have* a time zone - getTimezoneOffset uses the one local time zone that the JavaScript engine maintains somewhere.

I still don't feel like I have a clear answer to two fundamental
questions when designing DOM specs:

1. Is it ever appropriate to return Date objects from methods in the
DOM? If so, in what circumstances. Two cases where we are currently
considering using Date objects are:
* When the event related to a Notification [1] happened, or is set to
happen. What we need here is a timezone-less timestamp.
* When expressing when a scheduled task [2] is set to fire. The task
is set to fire at a designated point in time. I.e. a timezone-less
timestamp. Though in the future it would be nice to support scheduled
tasks that are set to happen in a particular time+timezone.

2. Is it ever appropriate to return a Date object from a "readonly"
property. This seems like a bad idea if we can't freeze it since it
would mean that if someone modifies the Date object, all other
consumers would see a changed date, and the property wouldn't really
be readonly. We could return a new Date instance each time the getter
is run, but that would mean that x.prop !== x.prop which seems

However this thread does seem to make it clear that it is
inappropriate to design an API which accepts Date objects as input, if
that API wants to enable the caller to provide a time+timezone. This
since it is not possible to create Date objects for arbitrary
timezones, but rather only for the users current timezone. So a caller
couldn't specify timezone.

Possibly this will be remedied in the future. But for APIs that are
shipping in the near future, this limitation seems to exist.

Such an API could instead separate the timestamp and timezone inputs.
Potentially the timestamp part could use a Date object. Again, it's
unclear if using a Date object to represent the timestamp would be

A concrete example here is the create-new-scheduled-task API in [3].
If we wanted to expand this API to support specifying a timezone in
addition to the timestamp, we would have to add a separate argument,
rather than simply relying on Date objects. And possibly we should
stop using Date objects entirely, even if we don't want timezone


/ Jonas

More information about the es-discuss mailing list