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 [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

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] https://mail.mozilla.org/pipermail/es-discuss/2013-February/028847.html
[4] https://mail.mozilla.org/pipermail/es-discuss/2013-February/028857.html

/ 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]: https://mail.mozilla.org/pipermail/es-discuss/2013-February/028847.html
[4]: https://mail.mozilla.org/pipermail/es-discuss/2013-February/028857.html