Invalid ios Timezone: US/Pacific

[PaulWoitaschek]

We are seeing a crash on iOS where an old timezone, US/Pacific is declared.

kotlin.RuntimeException: Unable to acquire the offset at instant 2021-01-20T15:59:38.842138051Z for zone US/Pacific

I don't fully understand what's happening here. Our iOS developers say that it's related to this issue:
https://stackoverflow.com/questions/19819268/convert-ios-localtimezone-to-a-knowntimezone

The iOS stacktraces aren't present for release frameworks but I think it boils down to this line of code:

Clock.System.now().toLocalDateTime(TimeZone.currentSystemDefault())

The issue occurs on kotlinx-datetime 0.1.1.
Its happening throughout all ios versions.

[dkhalanskyjb]

Thank you for the report! I was able to reproduce your issue by running

Clock.System.now().toLocalDateTime(TimeZone.of("US/Pacific"))

in the iOS simulator on 0.1.1. However, in the current master branch, the issue does not reproduce. I don't have an idea currently what causes this and will need to look for a possible workaround. For now, is it possible for you to build a snapshot of our current master locally, use that and see if it helps?

[PaulWoitaschek]

Out of interest: What exatly do you mean by iOS simulator?
Is this the same as the iosX64 target?
That crashes for me with a No timezone found with zone ID 'US/Pacific'

[dkhalanskyjb]

Yep, iosX64 runs the code in the iOS simulator.

Though the message is different, this must be the same problem as what you've reported initially, yes. Does the crash occur on the master branch as well?

[dkhalanskyjb]

Uhh... I managed to find the root cause.

If we open the Swift console and look at the output of NSTimeZone.knownTimeZoneNames and NSTimeZone.abbreviationDictionary, it turns out that US/Pacific is not mentioned in any of these. Our earlier version of the integration with Darwin–the one in 0.1.1–kept a cache of NSTimeZone objects to avoid their costly construction, and the list of time zones to be cached was taken from knownTimeZoneNames, as, according to https://developer.apple.com/documentation/foundation/nstimezone/1387223-knowntimezonenames, it contains

the IDs of all the time zones known to the system.

(emphasis mine). Evidently, the documentation is misleading: the system does know about some other time zones, as can be seen by explicitly calling NSTimeZone(name: "US/Pacific")!.

The implementation of Darwin integration that is currently in master does not need to keep a cache and instead always constructs a new NSTimeZone object, so even the names outside of knownTimeZoneNames are recognized. Though I'm not even sure if we want to support such behavior.

So, the workaround is to use a time zone from the list of names available in TimeZone.availableZoneIds.

[dkhalanskyjb]

Amusingly, even though there is no US/Pacific in knownTimeZoneNames, the documentation (https://developer.apple.com/documentation/foundation/nstimezone/1387258-abbreviationdictionary) explicitly uses it as an example!

Note that more than one time zone may have the same abbreviation—for example, US/Pacific and Canada/Pacific both use the abbreviation “PST.” In these cases, abbreviationDictionary chooses a single name to map the abbreviation to.

[dkhalanskyjb]

This doesn't reproduce for me on 0.2.0, so closing the issue.