Time zone offsets for any time zone, possible change to Date functionality (i18n)

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Mon Apr 15 11:13:19 PDT 2013


On Apr 15, 2013, at 9:23 , Dean Landolt wrote:

> On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> wrote:
> 
>> On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
>> 
>> > On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> wrote:
>> >
>> >> 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.
>> 
>> No, Date instances are in UTC - read the spec.
>> https://mail.mozilla.org/pipermail/es-discuss/2013-March/028928.html
>  
> I believe you're misunderstanding me.

That's always possible. What did I misunderstand, and what did you really mean?

>> 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.
>  
> You're suggesting that implicit, hidden global state is the right thing?

I said no such thing. I only said that it's different from instance data.

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

The other example I'm aware of is the default locale, and we addressed that by adding locales arguments to the locale sensitive functionality in the internationalization API. We similarly addressed the default time zone issue by adding a timeZone property in the options argument of DateTimeFormat and the Date.prototype.toLocale*String methods, and in the latest draft of the internationalization API spec that allows for the complete set of IANA time zone names. In this thread, Nebojša and Sorin proposed to add time zone arguments to other functions. These are all steps towards making the runtime's default time zone irrelevant. Your proposals need to be seen in this context, not just in the old ES5 context of a pervasively used implicit global time zone.

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

Together with the sample code below, this sounds like a third variant: Date instances by default don't own their time zone, but the methods do a property lookup for the time zone on Date instances, which by default gets the property of Date.prototype, but can be overridden by adding the property to the instance directly. Is that what you mean?

Also, when you say "locale-specific methods", do you really mean just the locale dependent methods (toLocaleString, toLocaleTimeString, toLocaleDateString), or do you mean all methods that depend on the local time zone (including the constructor, getTimeZoneOffset, getHour, etc.)?

Now, recording the default time zone as a property of Date.prototype and making some methods depend on it means in typical multi-component web applications that one component can change the default time zone and thus affect the behavior of other components, and may open a communications channel between components that are not supposed to communicate. We discussed similar proposals for the default locale during the development of the internationalization API, but rejected them because of these issues.

> > If you want to alter the timezone used for locale methods on a specific instance just set this property.
> 
> Changing the property would affect all instances that have Date.prototype as their prototype, not just "a specific instance".
> 
> 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:
> 
> 
>     Date.prototype.localeTimezone;
>     // 'America/New_York'
>     var d = new Date('2013-04-15Z');
>     // Sun Apr 14 2013 20:00:00 GMT-0400 (EDT)
>     +d;
>     // 1365984000000
>     d.localeTimezone = 'America/Los_Angeles';
>     // 'America/Los_Angeles'
>     d;
>     // Sun Apr 14 2013 20:00:00 GMT-0700 (PDT)

Why didn't the hours change here? Midnight UTC should be 17:00:00 in PDT.

>     +d;
>     // 1365984000000
>     var e = new Date(d);
>     // Sun Apr 14 2013 20:00:00 GMT-0400 (EDT)
>     Date.prototype.localeTimezone = 'America/Los_Angeles';
>     e;
>     // Sun Apr 14 2013 20:00:00 GMT-0700 (PDT)

And here?

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



More information about the es-discuss mailing list