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