On Mon, Jul 22, 2013 at 7:07 AM, Mark S. Miller <erig...@google.com> wrote: > For *all* of these, what benefits to Date objects provide over just using > numbers?
That is indeed the question. I think we attempted to use Date objects in an effort to be more "javascripty" and less "DOM doing it's own thing". But this thread is leading me to believe that using Date objects in the DOM is possibly never appropriate. / Jonas > On Sun, Jul 21, 2013 at 11:05 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg >> <ecmascr...@lindenbergsoftware.com> wrote: >> > >> > On Jul 17, 2013, at 16:59 , Jonas Sicking <jo...@sicking.cc> wrote: >> > >> >> On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie <bben...@mozilla.com> >> >> wrote: >> >>> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote: >> >>>> >> >>>> On Jul 17, 2013, at 16:51 , Brandon Benvie <bben...@mozilla.com> >> >>>> wrote: >> >>>> >> >>>>> On 7/17/2013 4:42 PM, Brandon Benvie wrote: >> >>>>>> >> >>>>>> On 7/17/2013 4:36 PM, Jonas Sicking wrote: >> >>>>>>> >> >>>>>>> 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? >> >>>>>> >> >>>>>> What happens if the timezone changes between the creation of two >> >>>>>> Date >> >>>>>> objects, such as for daylight savings or the user changes their >> >>>>>> system >> >>>>>> timezone? >> >>>>> >> >>>>> Having just tested this, it is possible in SM to get two Dates that >> >>>>> report different values from getTimezoneOffset. >> >>>> >> >>>> How? >> >>>> >> >>>> Norbert >> >>>> >> >>> >> >>> Create a Date object, change the system timezone, create a second Date >> >>> object. They reflect the timezone at time of Date object creation, not >> >>> a >> >>> static one. >> >> >> >> That doesn't reflect what I'm seeing. I see the timezone of all Date >> >> objects changing whenever the timezone is update. Existing instances >> >> are also changed. >> > >> > Seeing getTimezoneOffset change for *all* Date objects is what I expect >> > because none of them actually *have* a time zone - getTimezoneOffset uses >> > the one local time zone that the JavaScript engine maintains somewhere. >> >> I still don't feel like I have a clear answer to two fundamental >> questions when designing DOM specs: >> >> 1. Is it ever appropriate to return Date objects from methods in the >> DOM? If so, in what circumstances. Two cases where we are currently >> considering using Date objects are: >> * When the event related to a Notification [1] happened, or is set to >> happen. What we need here is a timezone-less timestamp. >> * When expressing when a scheduled task [2] is set to fire. The task >> is set to fire at a designated point in time. I.e. a timezone-less >> timestamp. Though in the future it would be nice to support scheduled >> tasks that are set to happen in a particular time+timezone. >> >> 2. Is it ever appropriate to return a Date object from a "readonly" >> property. This seems like a bad idea if we can't freeze it since it >> would mean that if someone modifies the Date object, all other >> consumers would see a changed date, and the property wouldn't really >> be readonly. We could return a new Date instance each time the getter >> is run, but that would mean that x.prop !== x.prop which seems >> surprising. >> >> >> However this thread does seem to make it clear that it is >> inappropriate to design an API which accepts Date objects as input, if >> that API wants to enable the caller to provide a time+timezone. This >> since it is not possible to create Date objects for arbitrary >> timezones, but rather only for the users current timezone. So a caller >> couldn't specify timezone. >> >> Possibly this will be remedied in the future. But for APIs that are >> shipping in the near future, this limitation seems to exist. >> >> Such an API could instead separate the timestamp and timezone inputs. >> Potentially the timestamp part could use a Date object. Again, it's >> unclear if using a Date object to represent the timestamp would be >> appropriate. >> >> A concrete example here is the create-new-scheduled-task API in [3]. >> If we wanted to expand this API to support specifying a timezone in >> addition to the timestamp, we would have to add a separate argument, >> rather than simply relying on Date objects. And possibly we should >> stop using Date objects entirely, even if we don't want timezone >> support. >> >> [1] http://notifications.spec.whatwg.org/#notification >> [2] http://www.w3.org/2012/sysapps/web-alarms/#interface-scheduledtask >> [3] http://www.w3.org/2012/sysapps/web-alarms/#taskscheduler >> >> / Jonas >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
