<div dir="ltr"><div>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.<br>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 15, 2013 at 9:33 AM, Claude Pache <span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>Le 15 avr. 2013 à 14:43, Dean Landolt <<a href="mailto:dean@deanlandolt.com" target="_blank">dean@deanlandolt.com</a>> a écrit :</div>

<br><blockquote type="cite"><div><div class="h5"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg <span dir="ltr"><<a href="mailto:ecmascript@lindenbergsoftware.com" target="_blank">ecmascript@lindenbergsoftware.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:<br>
<br>
> I'll add this as a second option to the strawman.<br>
><br>
><br>
> 2013/4/9 Sorin Mocanu <<a href="mailto:sorinmocanu@google.com" target="_blank">sorinmocanu@google.com</a>><br>
> Thank you Nebojša.<br>
> 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.<br>
><br>
> For example:<br>
> var date = Date.withTimeZone("America/Los_Angeles", 2013, 3, 9, 15, 11, 0);<br>
> var date = Date.withTimeZone("America/Los_Angeles", 1365545496000);<br>
> date.getHours(); // 15<br>
> date.getUTCHours(); // 22<br>
<br>
</div><div>> Sorin Mocanu, Software Engineer<br>
> Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland | 8002 Zurich<br>
<br>
</div>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. </blockquote><div><br><br></div>



<div>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. <b>This</b> 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.<br>



<br>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<b></b> 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.<br>



<br>All the while <b>nothing</b> 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?<br>



<br>[snipped the rest]<br>
</div></div><br></div></div></div></div><div class="im">
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>

</div></blockquote><br></div><div>Hi Dean,</div><div><br></div><div>What would be the behaviour of the following steps:</div><div><br></div><div>(1) store a Date object `d` locally using IndexedDB;</div><div>(2) change the timezone of the operating system, and maybe restart the browser;</div>

<div>(3) retrieve the date `d` stored in step 1.</div><div><br></div><div>In what timezone will be the retrieved date? and in what timezone should it be?</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<span class="HOEnZb"><font color="#888888"><div><br></div><div><div><br></div></div><div>—Claude</div><div><br></div><div><br></div><div><br></div><div><br></div><br></font></span></div></blockquote></div><br></div>