The issue with EWT offset.

wclr commented 7 months ago

The concreate case: 5 dec 1942, at this time it was EWT (Eastern War Time) offset -4h.

Here is an excerpt from tzdata distribution for the period:

TZ="America/New_York"
-   -   -045602 LMT
...
1940-09-29  01  -05 EST
1941-04-27  03  -04 EDT 1
1941-09-28  01  -05 EST
1942-02-09  03  -04 EWT 1
1945-08-14  19  -04 EPT 1
1945-09-30  01  -05 EST
..

timezonecomplete code:


import data from "tzdata/tzdata.js"
import * as tz from "timezonecomplete/dist/lib/timezone.js"
import { TzDatabase } from "timezonecomplete/dist/lib/tz-database.js"

TzDatabase.init(data)

const offset = tz
  .zone("America/New_York", true)
  .offsetForZone(1942, 12, 5, 0, 0, 0, 0)

console.log("offset", offset) -- 300

Offset is 300, thouh should be 240.

I didn't dive deep into the issue, so first need to check if the input date contains the info this time change, at least I don't see EWT mentions in tzdata.

rogierschouten commented 2 months ago

The latest TZ database as downloaded doesn't contain it. Where did you get your info?

# Zone  NAME        STDOFF  RULES   FORMAT  [UNTIL]
        #STDOFF -4:56:01.6
Zone America/New_York   -4:56:02 -  LMT 1883 Nov 18 17:00u
            -5:00   US  E%sT    1920
            -5:00   NYC E%sT    1942
            -5:00   US  E%sT    1946
            -5:00   NYC E%sT    1967
            -5:00   US  E%sT

wclr commented 2 months ago

https://data.iana.org/time-zones/tzdb/to2050.tzs

From NEWS file:

The experimental distribution contains a file to2050.tzs that
contains what should be the output of 'zdump -i -c 2050' on
primary zones.  If this file is available, 'make check' now checks
that zdump generates this output.

Do you know about this file? I didn't actually dive deep in to the issue, but seems there is some problem with current standard/traditional tzdb source of data that may lack this kind of detail.

rogierschouten / tzdata-generate

The issue with EWT offset. #15