Frozen Date objects?

Norbert Lindenberg ecmascript at
Wed Jul 17 17:35:51 PDT 2013

On Jul 17, 2013, at 16:48 , Jonas Sicking <jonas at> wrote:

> On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking <jonas at> wrote:
>> 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.
> [3]
> [4]

And then there was this thread, which ended with your largely correct idea for how to implement floating time alarms:


More information about the es-discuss mailing list