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

Dean Landolt dean at deanlandolt.com
Mon Apr 15 09:23:11 PDT 2013


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.


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


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


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


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/bf9c7f75/attachment.html>


More information about the es-discuss mailing list