<div dir="ltr">+1. We should do something along these lines. I especially agree with "<span style="font-family:arial,sans-serif;font-size:13px">Having [X] depend on an implicit global [Y] is madness" for any X and Y.</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 10:01 AM, Dean Landolt <span dir="ltr"><<a href="mailto:dean@deanlandolt.com" target="_blank">dean@deanlandolt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 18, 2013 at 12:44 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 Jul 17, 2013, at 20:35 , Brendan Eich <<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>> wrote:<br>
<br>
> Norbert Lindenberg wrote:<br>
>> On Jul 17, 2013, at 17:27 , Mark S. Miller<<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>>  wrote:<br>
>><br>
>>> 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.<br>



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



>><br>
>> If you want to lock down the behavior of getTimezoneOffset, or create illusory behavior,<br>
><br>
> Mark wants to do this from JS, not from under the hood (usually via C++) using VM internal APIs.<br>
<br>
</div>Sorry, I missed that bit.<br>
<br>
In that case, you'd have to replace the Date function and all Date methods that depend on the local time zone: Date as a function; the Date constructor for 2 or more arguments; parse; toString & friends; getFullYear, getMonth, and their non-UTC friends; getTimezoneOffset, setMilliseconds, setSeconds, and their non-UTC friends. That's a lot more work, but it still doesn't affect Date instances directly.<br>


</blockquote><div><br><br></div></div></div><div><i>Or</i> the spec could redefine those functions to use an instance property lookup which defines the appropriate timezone. I'd suggested this several months back, and partly for this reason (it's also a much needed feature, and more idiomatically javascripty). Having Dates depend on an implicit global timezone is madness. Using a prototype property would allow Date objects to have their timezone explicitly set or modified, and they'd be possible to freeze. `Date.prototype.timezone` (or whatever it would be called) could then float with the system's timezone (or be explicitly set and/or frozen too). Oh, and this could be cleanly polyfilled to make dates and timezones suck less today. I still can't think of any downsides.<br>


</div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div>