Frozen Date objects?
jonas at sicking.cc
Wed Jul 17 16:48:55 PDT 2013
On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich <brendan at mozilla.com> 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?
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22714 (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  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.
More information about the es-discuss