On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking <[email protected]> wrote: > On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren <[email protected]> wrote: >> On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
