DST time zone offsets wrong pre-2006 on MingwX64

[jeffdgr8]

Running the following code:

logTzDst(TimeZone.of("America/Los_Angeles"))
logTzDst(TimeZone.of("America/Denver"))
logTzDst(TimeZone.of("America/Chicago"))
logTzDst(TimeZone.of("America/New_York"))

private fun logTzDst(timeZone: TimeZone) {
    println(timeZone)
    var last: String? = null
    for (y in 2024 downTo 1900) {
        val date = LocalDate.parse("$y-08-01")
            .atTime(0, 0)
            .toInstant(timeZone)
        val offset = date.toString().substring(11)
        if (offset != last) {
            println(date)
            println("...")
        }
        last = offset
    }
    println()
}

MingwX64 0.6.0 doesn't adjust for daylight savings time before 2006:

America/Los_Angeles
2024-08-01T07:00:00Z
...
2005-08-01T08:00:00Z
...

America/Denver
2024-08-01T06:00:00Z
...
2005-08-01T07:00:00Z
...

America/Chicago
2024-08-01T05:00:00Z
...
2005-08-01T06:00:00Z
...

America/New_York
2024-08-01T04:00:00Z
...
2005-08-01T05:00:00Z
...

MingwX64 0.5.0 naively adjusts for daylight savings time for all years, which is mostly correct for the previous century, but not for some of those years and pre-1918:

America/Los_Angeles
2024-08-01T07:00:00Z
...

America/Denver
2024-08-01T06:00:00Z
...

America/Chicago
2024-08-01T05:00:00Z
...

America/New_York
2024-08-01T04:00:00Z
...

JVM/iOS/macOS/Linux properly adjust for daylight savings time in the correct years:

America/Los_Angeles
2024-08-01T07:00:00Z
...
1949-08-01T08:00:00Z
...
1948-08-01T07:00:00Z
...
1947-08-01T08:00:00Z
...
1945-08-01T07:00:00Z
...
1941-08-01T08:00:00Z
...
1919-08-01T07:00:00Z
...
1917-08-01T08:00:00Z
...

America/Denver
2024-08-01T06:00:00Z
...
1964-08-01T07:00:00Z
...
1945-08-01T06:00:00Z
...
1941-08-01T07:00:00Z
...
1920-08-01T06:00:00Z
...
1917-08-01T07:00:00Z
...

America/Chicago
2024-08-01T05:00:00Z
...
1917-08-01T06:00:00Z
...

America/New_York
2024-08-01T04:00:00Z
...
1917-08-01T05:00:00Z
...

[dkhalanskyjb]

We use an approach similar to https://learn.microsoft.com/en-us/windows/win32/api/timezoneapi/ns-timezoneapi-dynamic_time_zone_information in our implementation (to my knowledge, it's the only TimeZone API available to us on mingwX64), which queries the Windows registry to obtain timezone information. When I run regedit.exe and open Computer/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Time Zones/Pacific Standard Time/Dynamic DST, I see just two years of historical data: 2006 and 2007. Anything before that is unspecified.

Linux and MacOS typically provide much more complete information in their timezone databases based on https://data.iana.org/, which is why you see accurate results there.

Short of giving our users an option to use a timezone database other than the system one (#201), I don't think we can do anything about this issue. Just ignoring the Windows registry and always supplying our own version of timezone rules is also questionable, as in our research, we've seen Windows users changing the registry values and relying on those changes.

[jeffdgr8]

Interesting, it appears the Windows time zone information isn't really meant to give accurate information for past dates.

The issue I'm experiencing is the fact that the dates are different between platforms in a test in my Kotlin Multiplatform library. If there's not a system API to properly query past time zone information, it might make sense to embed the IANA database in the library, at least for MingwX64.

[ilya-g]

@dkhalanskyjb Can it be that we're interpreting the registry data incorrectly in the sense that we should propagate the time zone rules specified by the FirstEntry year to all previous years?

[ilya-g]

@jeffdgr8 Regarding your test, usually time zone databases contain the accurate transition information only starting from the year 1970, so it is expected that the offset rules for the dates before that can be incorrect for certain time zones.

[jeffdgr8]

The test happens to be using a date in 1985. So it did work before 0.6.0.

JVM, macOS, iOS, and Linux do all have accurate time zone offsets going back to the beginning of daylight savings time in 1918 though.

[dkhalanskyjb]

Looks like Ilya is right: almost all time zones behave like the corresponding native Windows objects for earlier years when we extrapolate the first available rule to them. Except the Central Brazilian Time Zone for some reason 🤷. Luckily, neither the registry nor what Windows actually returns is correct, so I won't bother ensuring consistency there.