Frozen Date objects?

Mark S. Miller erights at google.com
Mon Jul 22 07:07:32 PDT 2013


For *all* of these, what benefits to Date objects provide over just using
numbers?



On Sun, Jul 21, 2013 at 11:05 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg
> <ecmascript at lindenbergsoftware.com> wrote:
> >
> > On Jul 17, 2013, at 16:59 , Jonas Sicking <jonas at sicking.cc> wrote:
> >
> >> On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie <bbenvie at mozilla.com>
> wrote:
> >>> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
> >>>>
> >>>> On Jul 17, 2013, at 16:51 , Brandon Benvie <bbenvie at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130722/973e20ff/attachment-0001.html>


More information about the es-discuss mailing list