On Mon, Apr 15, 2013 at 10:01 AM, Dean Landolt <d...@deanlandolt.com> wrote:
> 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.
>
To drive this point home perhaps a suitable key would be `localeTimezone`
to communicate that this is the timezone used by the locale-specific
methods. It's seems unlikely to conflict with popular libraries, but I
could do a quick survey and code search to confirm.
> 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
