Frozen Date objects?
ecmascript at lindenbergsoftware.com
Wed Jul 17 17:35:51 PDT 2013
On Jul 17, 2013, at 16:48 , Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking <jonas at sicking.cc> 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  to use
>> Date objects in the ScheduledTask  API since the time that a task
>> is scheduled sometimes represents a point-in-time rather than a
>> particular time+timezone
>>  http://www.w3.org/2012/sysapps/web-alarms/
>>  http://www.w3.org/2012/sysapps/web-alarms/#interface-scheduledtask
>> / Jonas
> And then there is the thread started at , and this particular email
>  which seems to conclude that Date objects in fact are just
> timestamps, and not timezone+timestamp.
>  https://mail.mozilla.org/pipermail/es-discuss/2013-February/028847.html
>  https://mail.mozilla.org/pipermail/es-discuss/2013-February/028857.html
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