<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 15, 2013 at 11:46 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:<br>
<br>
> On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg <<a href="mailto:ecmascript@lindenbergsoftware.com">ecmascript@lindenbergsoftware.com</a>> wrote:<br>
><br>
</div><div class="im">>> 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.<br>
><br>
><br>
> 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.<br>


<br>
</div>No, Date instances are in UTC - read the spec.<br>
<a href="https://mail.mozilla.org/pipermail/es-discuss/2013-March/028928.html" target="_blank">https://mail.mozilla.org/pipermail/es-discuss/2013-March/028928.html</a><br></blockquote><div> </div><div>I believe you're misunderstanding me.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The time zone of the host system is, as you say, global state. Confusing instance data and global state has real hazards in many areas of software development.<br></blockquote><div> </div><div>You're suggesting that implicit, hidden global state is the right thing? Can you think of another example in the language of this kind of ambient state? If there is I bet it'd look like a bug.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> 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.<br>


<br>
</div>So which one are you proposing: having "Date instances ... own their timezone" or "slap the system timezone as a symbol on Date.prototype and correct all locale-specific date methods to respect this symbol"? These are not the same.<br>

</blockquote><div> </div><div>As you've said, the underlying "value" of a date is UTC. But there are a bunch of locale-specific methods that depend on a global timezone state. I'm simply suggesting that instead of this global state it would be better if these locale-specific methods resolved the appropriate timezone instead by using an explicit property (using prototypal inheritance for a sane default). Again, this timezone is not part of the "value" of a date, and would not be preserved on copy. It simply codifies something that's already happening, allowing it to be controlled in an idiomatic way.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> If you want to alter the timezone used for locale methods on a specific instance just set this property.<br>
<br>
</div>Changing the property would affect all instances that have Date.prototype as their prototype, not just "a specific instance".</blockquote></div><br></div><div class="gmail_extra">Sure, if you set the property on Date.prototype, but I didn't say to do that. Perhaps code will clear things up -- here's an example of using my proposal and its effects:<br>

<br><br></div><div class="gmail_extra">    Date.prototype.localeTimezone;<br></div><div class="gmail_extra">    // 'America/New_York'<br></div><div class="gmail_extra">    var d = new Date('2013-04-15Z');<br>

    // Sun Apr 14 2013 20:00:00 GMT-0400 (EDT)<br></div><div class="gmail_extra">    +d;<br>    // 1365984000000<br></div><div class="gmail_extra">    d.localeTimezone = 'America/Los_Angeles';<br>    // 'America/Los_Angeles'</div>

<div class="gmail_extra">    d;<br>    // Sun Apr 14 2013 20:00:00 GMT-0700 (PDT)<br></div><div class="gmail_extra">    +d;<br></div><div class="gmail_extra">    // 1365984000000<br></div><div class="gmail_extra">    var e = new Date(d);<br>

    // Sun Apr 14 2013 20:00:00 GMT-0400 (EDT)<br></div><div class="gmail_extra">    Date.prototype.localeTimezone = 'America/Los_Angeles';<br></div><div class="gmail_extra">    e;<br>    // Sun Apr 14 2013 20:00:00 GMT-0700 (PDT)<br>

<br><br></div><div class="gmail_extra">Only locale-specific methods are affected -- we're just making the global lookup for timezone into a prototypal one. I can't imagine anything more idiomatic.<br></div></div>