Perhaps I wasn't clear: I was proposing the timezone property as purely
informative for the locale methods. The Date constructor used to revive the
IDB value will dictate the date's timezone, so no, the cloned date wouldn't
carry its timezone with it. However, in my proposed world it would be
possible to create a Date subclass that will serialize a date with its
timezone tag and revive it always frozen to that timezone. This kind of
serialization couldn't be stored directly as a Date in IDB, but that's not
much of a limitation. Same goes for JSON, which doesn't even have a native
Date so you need a custom cons anyway.
On Mon, Apr 15, 2013 at 9:33 AM, Claude Pache <claude.pa...@gmail.com>wrote:
>
> Le 15 avr. 2013 à 14:43, Dean Landolt <d...@deanlandolt.com> a écrit :
>
>
>
>
> On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg <
> ecmascr...@lindenbergsoftware.com> wrote:
>
>>
>> On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
>>
>> > I'll add this as a second option to the strawman.
>> >
>> >
>> > 2013/4/9 Sorin Mocanu <sorinmoc...@google.com>
>> > Thank you Nebojša.
>> > How about if the [timezone] parameter would only be passed at the
>> construction of the Date object? That would (perhaps) allow a user to
>> centralize timezone validation as well.
>> >
>> > For example:
>> > var date = Date.withTimeZone("America/Los_Angeles", 2013, 3, 9, 15, 11,
>> 0);
>> > var date = Date.withTimeZone("America/Los_Angeles", 1365545496000);
>> > date.getHours(); // 15
>> > date.getUTCHours(); // 22
>>
>> > Sorin Mocanu, Software Engineer
>> > Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland
>> | 8002 Zurich
>>
>> I'm afraid this would be quite confusing. Many people believe already
>> that Date instances are in some local time zone, which they aren't, and
>> this would lead even more astray.
>
>
>
> Of course Date instances are in some local timezone -- the timezone of the
> host system. This data isn't explicitly carried along with each date --
> instead it's just more implicit global state. But it's naive and even
> hazardous to pretend a Date instance has no timezone component -- to say
> this with a strait face would requiring removing the locale-specific date
> methods. *This* is what is leading so many astray. Further, I've found
> that changing the host timezone can wreak havoc on this implicit state in
> some environments. I couldn't find anything in the spec about expected
> behavior but there are subtle but real hazards lurking here.
>
> Previously I'd suggested that Date instances should just own their
> timezone. Make explicit what's already there implicitly -- slap the system
> timezone as a symbol on Date.prototype and correct all locale-specific date
> methods to respect this symbol instead of some hidden global state. Of
> course this has no** impact on a date's underlying value, just on the
> behavior of its locale methods. If you want to alter the timezone used for
> locale methods on a specific instance just set this property. You can get a
> Date constructor pinned to a specific timezone through subclassing. Weak
> implementations lacking proper tz support would freeze this property on
> fresh dates.
>
> All the while *nothing* about Date objects and their methods would change
> -- it would be fully backward compatible. With a little more thought it
> could be made polyfillable (perhaps it doesn't need to be a symbol at all,
> if a suitable name can be found that is unlikely to collide with existing
> libs). What's not to like? More specifically, in what way is the current
> state of affairs better?
>
> [snipped the rest]
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> Hi Dean,
>
> What would be the behaviour of the following steps:
>
> (1) store a Date object `d` locally using IndexedDB;
> (2) change the timezone of the operating system, and maybe restart the
> browser;
> (3) retrieve the date `d` stored in step 1.
>
> In what timezone will be the retrieved date? and in what timezone should
> it be?
>
> I have not try the experiment, but my educated guess is that (1) the value
> of`d.getUTCHours()` would remain invariant and (2) the value of
> `d.getHours()` would vary according to the change operated in step (2). In
> other words, `getHours`, `setHours`, etc. do have (unfortunately) an
> implicit parameter, which is the timezone provided by the system, but that
> parameter is not part of the `Date` instance.
>
> Now, do you propose that `d` should hold its timezone information, so that
> it would remain in the old timezone, but `dCloned = new Date(d)` would be
> in the new timezone? *That* seems hazardous to me.
>
>
> —Claude
>
>
>
>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
