Frozen Date objects?

Mark S. Miller erights at google.com
Wed Jul 17 17:27:49 PDT 2013


This is unfortunate. It does answer Anne's question though, in an
unpleasant way: Date instances cannot be immutable; they can be at best
readonly. Despite lack of any authorization to track the user's position,
Date instances make visible their machine's mutable current position, as
coarsened to the timezone.

Just as a Date instance snapshots the time *when* it was created, I think
it should also snapshot the timezone *where* it was created. Then it would
be possible to contemplate immutable Date instances. Only the Date
constructor should give the ability to sense changes to time and place, not
the instances it makes. Virtualizing the Date constructor (replacing it
with a faux Date constructor) should be adequate to create illusory paths
through time and space, without needing to wrap all the instances it
creates with faux Date instances.



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.
>
> Norbert
> _______________________________________________
> 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/20130717/7482d940/attachment.html>


More information about the es-discuss mailing list