Frozen Date objects?

Jonas Sicking jonas at
Wed Jul 17 16:48:55 PDT 2013

On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking <jonas at> wrote:
> On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren <annevk at> wrote:
>> On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich <brendan at> wrote:
>>> Anne van Kesteren wrote:
>>>> Right, but we all use a number (and newer specs reflect that). Per
>>>> your explanation above that makes sense and I guess we should continue
>>>> to do that then. Not sure if startTime can still be changed.
>>> I hope so. At the very least, can you forward my reply to the editors
>>> responsible for those Date uses?
>> (I'm not aware of
>> usage beyond HTML, but I'll be on the lookout.)
>> Having gone through all this, for the case I was considering it for it
>> still seems relevant and the questions remain. Namely, communicating
>> to the end-user notification system at what point an event for which
>> the notification is generated will be happening or has happened. And
>> exposing the communicated time back to the developer.
> I'm still confused as to when it's correct for an API to return a Date object.
> At least in SpiderMonkey it's impossible to create Date objects that
> represent a timezone other than the user's current timezone. I.e.
> getTimezoneOffset returns the same value for all object instances.
> Maybe that's a limitation that's implementation specific and is there
> because no current JS APIs happen to need it?
> But that makes it impossible to create, for example a Calendar API
> which returns a Date object which represents the time and timezone of
> when a particular event is going to happen.
> So at least in SpiderMonkey a Date object is not a time+timezone, but
> rather simply a timestamp whose API always represents that timestamp
> in a particular (but possibly changing) timezone.
> 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?
> Another question is if it's wrong of the Task Scheduler API [1] to use
> Date objects in the ScheduledTask [2] API since the time that a task
> is scheduled sometimes represents a point-in-time rather than a
> particular time+timezone
> [1]
> [2]
> / Jonas

And then there is the thread started at [3], and this particular email
[4] which seems to conclude that Date objects in fact are just
timestamps, and not timezone+timestamp.


/ Jonas

More information about the es-discuss mailing list