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

Dean Landolt dean at deanlandolt.com
Mon Apr 15 15:50:31 PDT 2013

On Mon, Apr 15, 2013 at 2:13 PM, Norbert Lindenberg <
ecmascript at lindenbergsoftware.com> wrote:

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

I wasn't suggesting Date instances be anything other than UTC. Based on
your other responses below I believe that misunderstanding was cleared up.
Thanks for bearing with me...

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

Sorry -- I read it as suggesting the current state of affairs was in some
way superior.

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

This is an improvement to be sure, but I don't think I understand how it
will have much impact on how pervasively the implicit global time zone is
dependent upon. The locale-dependent methods will still be just as
prominent and leaned on heavily I'd bet.

But I also don't see how the two approaches are in conflict at all -- to my
mind they complement each other nicely. Any `timeZone` properties in the
i18n formatting stuff would take precedence, of course, just as they do
today over the implicit global.

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

Perhaps my use of the word "own" was the wrong choice -- what I meant to
imply was that locale methods should first look to an "own" key -- I didn't
mean to imply this wouldn't fall through prototypally -- just the opposite.

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

All locale-dependent methods -- I should have made that more clear.

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.

Okay, I think we're at least talking about the same thing now. Though a
close reading suggests to me there may be a misunderstanding of the
fundamental OCap principles at issue here. There would be no channel that
isn't already in place -- Date instances are already mutable and
extensible. While I agree with the thrust of your point, it could just as
easily be said about any of the other built-ins, and much more seriously at
that. Any hazard from modifying Date.prototype.localeTimezone (or whatever
it's called) would beovershadowed by poorly modifying many of the other
built-in prototypes. Fortunately es5 gives us the tools to correct this.

And this is an important point -- I believe explicit (and freezable) state
is substantially more friendly for mutually suspicious code than an
implicit and underspecified global. I strongly suspect this would be a
welcome development for secure programming (MarkM, TomVC or one of the many
other OCap experts on this list please correct me if I'm wrong!), since it
gives us the opportunity to actually shut down a (potential) communications
channel present in the ambient environment.

We can certainly disagree about whether this is the right API but I believe
any argument based on POLA will only strengthen my case :)

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

Sorry -- my mistake.

>  >     +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?

Copy/paste of the same oversight :)

>  > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130415/451bef6d/attachment-0001.html>

More information about the es-discuss mailing list