|
7 | 7 |
|
8 | 8 | package kotlinx.datetime
|
9 | 9 |
|
10 |
| -import kotlinx.datetime.internal.Path |
11 |
| -import kotlinx.datetime.internal.TzdbOnFilesystem |
| 10 | +import kotlinx.datetime.internal.* |
12 | 11 | import platform.Foundation.*
|
13 | 12 |
|
14 | 13 | internal actual fun currentTime(): Instant = NSDate.date().toKotlinInstant()
|
15 | 14 |
|
16 |
| -internal actual val tzdbOnFilesystem = TzdbOnFilesystem(Path.fromString("/var/db/timezone/zoneinfo")) |
| 15 | +// iOS simulator needs a different path, hence the check. See https://github.com/HowardHinnant/date/pull/577 |
| 16 | +@OptIn(kotlinx.cinterop.ExperimentalForeignApi::class) |
| 17 | +internal actual val tzdbOnFilesystem = TzdbOnFilesystem(Path.fromString( |
| 18 | + if (kotlinxDatetimeRunningInSimulator) "/usr/share/zoneinfo" else "/var/db/timezone/zoneinfo")) |
| 19 | + |
| 20 | +internal actual fun currentSystemDefaultId(): String? { |
| 21 | + /* The framework has its own cache of the system timezone. Calls to |
| 22 | + [NSTimeZone systemTimeZone] do not reflect changes to the system timezone |
| 23 | + and instead just return the cached value. Thus, to acquire the current |
| 24 | + system timezone, first, the cache should be cleared. |
| 25 | +
|
| 26 | + This solution is not without flaws, however. In particular, resetting the |
| 27 | + system timezone also resets the default timezone ([NSTimeZone default]) if |
| 28 | + it's the same as the cached system timezone: |
| 29 | +
|
| 30 | + NSTimeZone.defaultTimeZone = [NSTimeZone |
| 31 | + timeZoneWithName: [[NSTimeZone systemTimeZone] name]]; |
| 32 | + NSLog(@"%@", NSTimeZone.defaultTimeZone.name); |
| 33 | + NSLog(@"Change the system time zone, then press Enter"); |
| 34 | + getchar(); |
| 35 | + [NSTimeZone resetSystemTimeZone]; |
| 36 | + NSLog(@"%@", NSTimeZone.defaultTimeZone.name); // will also change |
| 37 | +
|
| 38 | + This is a fairly marginal problem: |
| 39 | + * It is only a problem when the developer deliberately sets the default |
| 40 | + timezone to the region that just happens to be the one that the user |
| 41 | + is in, and then the user moves to another region, and the app also |
| 42 | + uses the system timezone. |
| 43 | + * Since iOS 11, the significance of the default timezone has been |
| 44 | + de-emphasized. In particular, it is not included in the API for |
| 45 | + Swift: https://forums.swift.org/t/autoupdating-type-properties/4608/4 |
| 46 | +
|
| 47 | + Another possible solution could involve using [NSTimeZone localTimeZone]. |
| 48 | + This is documented to reflect the current, uncached system timezone on |
| 49 | + iOS 11 and later: |
| 50 | + https://developer.apple.com/documentation/foundation/nstimezone/1387209-localtimezone |
| 51 | + However: |
| 52 | + * Before iOS 11, this was the same as the default timezone and did not |
| 53 | + reflect the system timezone. |
| 54 | + * Worse, on a Mac (10.15.5), I failed to get it to work as documented. |
| 55 | + NSLog(@"%@", NSTimeZone.localTimeZone.name); |
| 56 | + NSLog(@"Change the system time zone, then press Enter"); |
| 57 | + getchar(); |
| 58 | + // [NSTimeZone resetSystemTimeZone]; // uncomment to make it work |
| 59 | + NSLog(@"%@", NSTimeZone.localTimeZone.name); |
| 60 | + The printed strings are the same even if I wait for good 10 minutes |
| 61 | + before pressing Enter, unless the line with "reset" is uncommented-- |
| 62 | + then the timezone is updated, as it should be. So, for some reason, |
| 63 | + NSTimeZone.localTimeZone, too, is cached. |
| 64 | + With no iOS device to test this on, it doesn't seem worth the effort |
| 65 | + to avoid just resetting the system timezone due to one edge case |
| 66 | + that's hard to avoid. |
| 67 | + */ |
| 68 | + NSTimeZone.resetSystemTimeZone() |
| 69 | + val zone = NSTimeZone.systemTimeZone |
| 70 | + return zone.name |
| 71 | +} |
0 commit comments