On Apr 15, 2013, at 9:23 , Dean Landolt wrote:
> On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
> <ecmascr...@lindenbergsoftware.com> wrote:
>
>> On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
>>
>> > On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
>> > <ecmascr...@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.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
