Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

timezone-js doesn't handle static dst offset rules #36

Closed
divide0 opened this Issue Jul 16, 2012 · 7 comments

Comments

Projects
None yet
3 participants
Contributor

divide0 commented Jul 16, 2012

Example is Pacific/Apia, in the australasia file

Zone Pacific/Apia    12:33:04 - LMT 1879 Jul  5
            -11:26:56 - LMT 1911
            -11:30  -   SAMT    1950        # Samoa Time
            -11:00  -   WST 2010 Sep 26
            -11:00  1:00    WSDT    2011 Apr 2 4:00
            -11:00  -   WST 2011 Sep 24 3:00
            -11:00  1:00    WSDT    2011 Dec 30
             13:00  1:00    WSDT    2012 Apr 1 4:00
             13:00  -   WST

Notice that instead of referencing DST rules, they just put the DST offset.

Collaborator

longlho commented Jul 27, 2012

What exactly is the issue here? Is it related to issue #37? Can you provide some codes to reproduce the bug?

Contributor

divide0 commented Jul 27, 2012

The issue is that it doesn't adjust the time for dst.

In the tz def:
13:00 1:00 WSDT 2012 Apr 1 4:00

It has an offset of +13 and a static DST offset of +1 (not a rule reference), so the effective offset for times in dst shoudl be +14, but it is +13.

This happens because timezone-js only uses rules by reference. It doesn't find a rule for "1:00", so it doesn't apply any DST offset.

Contributor

divide0 commented Jul 27, 2012

            var dt = new timezoneJS.Date(Date.UTC(2012, 2, 1, 0, 0, 0, 0), "Pacific/Apia");
            console.log("Time (should be 14:00:00): " + dt.toString("EEE, dd MMM yyyy HH:mm:ss Z"));
            console.log("Offset in Hours (should be -14 hours): " + dt.getTimezoneOffset() / 60);

Output

LOG: Time (should be 14:00:00): Thu, 01 Mar 2012 13:00:00 WSDT
LOG: Offset in Hours (should be -14 hours): -13
Collaborator

longlho commented Jul 30, 2012

Gotcha! Thanks for the clarification I'll take a look at this

Contributor

jgable commented Aug 7, 2012

I found this great resource for the timezone files (don't be scared by the sketchy IP link) that gives a good description of static offsets:

The RULES column tells us whether daylight saving time is being observed:

  • A hyphen, a kind of null value, means that we have not set our clocks ahead of standard time.
  • An amount of time (usually but not necessarily “1:00” meaning one hour) means that we have set our clocks ahead by that amount.
  • Some alphabetic string means that we might have set our clocks ahead; and we need to check the rule the name of which is the given alphabetic string.

An example of a specific amount of time is:

Zone NAME GMTOFF RULES FORMAT [UNTIL]

Zone Pacific/Honolulu ... 1933 Apr 30 2:00
-10:30 1:00 HDT 1933 May 21 2:00
...

Hawaii tried daylight saving time for three weeks in 1933 and decided they didn’t like it. 8-) Note that the GMTOFF column always contains the standard time offset, so the wall clock time during this period was GMT − 10:30 + 1:00 = GMT − 9:30.

Collaborator

longlho commented Aug 7, 2012

lol thanks :) it's kinda tricky since some of the rules are in local time, which is the time we're trying to retrieve for certain zones so it gets confusing.

@divide0 divide0 added a commit to divide0/timezone-js that referenced this issue Feb 6, 2013

@divide0 divide0 Issue #36: timezone-js doesn't handle static dst offset rules
Create a pseudo rule when the DST offset of a Zone is specified as a duration instead of a rule reference.
8c4260e

@longlho longlho added a commit that referenced this issue Feb 8, 2013

@longlho longlho Merge pull request #57 from divide0/master
Fix Issue #36. timezone-js doesn't handle static dst offset rules
915b3f3
Contributor

divide0 commented Feb 9, 2013

this can be closed with the recent pull.

@divide0 divide0 closed this Feb 9, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment