currentSystemDefault() iOS crash with "Exception: Invalid zone ID: Europe/Paris"

[stefanhaustein]

Terminating app due to uncaught exception 'kotlinx.datetime.IllegalTimeZoneException', reason: 'Invalid zone ID: Europe/Paris'

(TimeZone.kt:78) |   | kfun:kotlinx.datetime.TimeZone.Companion#of(kotlin.String){}kotlinx.datetime.TimeZone
(TimeZone.kt:31) |   | kfun:kotlinx.datetime.TimeZone.Companion#currentSystemDefault(){}kotlinx.datetime.TimeZone

Device data for an example instance

• iPad11,6
• iOS 17.6.1 21G93

Kotlinx DateTime Version: 0.6.1

[dkhalanskyjb]

I've double-checked that TimeZone.currentSystemDefault() works on kotlinx-datetime 0.6.2 with both iOS 17.1.1 (before an update) and on 18.3.1 (after an update) on a physical (non-Simulator) iPhone 12 mini. I don't know where the difference between the two devices could come from or what custom settings your device has that causes this.

[stefanhaustein]

It's not my device, so I can't repro locally unfortunately; it's copied from an internal bug report. Given that it crashes inside currentSystemDefault() it doesn't look like something that could stem from our client code.

Could it be a problem with the "-9a420787" suffix? Not sure what it means / what triggers it / if something like this is always there?

[stefanhaustein]

P.S: Sorry, the hex string is probably a red herring -- it was added by our system to create a unique identifier. I have updated the original message from the report details with the exact strings

[stefanhaustein]

Any ideas how this could happen? Europe/Paris seems to be in your region database...

[dkhalanskyjb]

If the timezone is Europe/Paris-9a420787, then it means that this invocation

kotlinx-datetime/core/darwin/src/internal/TimeZoneNative.kt

Line 68 in e69f92f

return NSTimeZone.systemTimeZone.name to null

returned such a string, which is clearly an incorrect time zone name.

If the timezone is Europe/Paris, which is clearly a valid time zone name, it means we can no longer rely on the location of the timezone database in

kotlinx-datetime/core/darwinDevices/src/internal/TimeZoneNative.kt

Line 8 in e69f92f

internal actual fun defaultTzdbPath(): String = "/var/db/timezone/zoneinfo"

We can work around both, probably, but we do need to understand where the problem lies first.

[stefanhaustein]

Sorry about the red herring. The Time Zone was "Europe/Paris", and we see this for other time zones, too:

• Invalid zone ID: America/Mexico_City
• Invalid zone ID: Asia/Ho_Chi_Minh
• Invalid zone ID: Europe/Rome
• Invalid zone ID: Asia/Manila

Could you get the region database information from a native NSTimeZone object instead?

[dkhalanskyjb]

Could you get the region database information from a native NSTimeZone object instead?

That was the initial approach we took, but since https://developer.apple.com/documentation/foundation/timezone does not expose all the information we need, we had to change the implementation to query the filesystem directly. Actually, https://developer.apple.com/documentation/foundation/nstimezone/1387213-data also contains the data we need, but "Treat this data as an opaque object" is very clear in that we should not access it.

[stefanhaustein]

The comments here mention -DUSE_OS_TZDB=1... This alls seems a bit fragile.... Is the database large? Perhaps it could be included in the library as a fallback? It seems to be already in your project (for wasm)?

[dkhalanskyjb]

USE_OS_TZDB is a flag that's specific to that library.

Is the database large?

Yes, it's a couple of megabytes.

[stefanhaustein]

A colleague found this: https://www.reddit.com/r/jailbreak/comments/3ll1rf/tutorial_solution_how_to_fix_broken_timezone_in/

We don't think this is the issue here -- but maybe it's worthwhile adding the "simulator" path as a fallback?

[dkhalanskyjb]

If it turns out that there are devices where the simulator path exists, but the default path doesn't, then of course! When we get access to a device where the issue can be reproduced, we'll see which approach is the most promising.

[stefanhaustein]

These reports only started when we pulled in a new version of this API. Would a fallback to the previous implementation be an option, dropping the missing information in that case?

We have a significant number of these crashes, but we don't have access to a device where we can reproduce this.