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 [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] http://www.w3.org/2012/sysapps/web-alarms/
[2] http://www.w3.org/2012/sysapps/web-alarms/#interface-scheduledtask

/ Jonas

On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> 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]: http://www.w3.org/2012/sysapps/web-alarms/
[2]: http://www.w3.org/2012/sysapps/web-alarms/#interface-scheduledtask