The current implementation of TimeZone.current attempts to read from /etc/localtime which is not a path that exists on Windows. This leads to TimeZone.current always being GMT on Windows. Instead, this updates the implementation to call GetTimeZoneInformation, convert the Windows name to an ICU system timezone name, and initialize a timezone with that name (this matches the behavior of TimeZone on Swift 5.10 when it was based on CFTimeZone). This also restricts the default values for TZDEFAULT/TZDIR to Darwin + Linux where the paths are reasonable unlike Windows where we know these constants should never exist to avoid accidental usage in the future.
There's likely more work to be done here for Windows for a full solution (to allow in some way for developers to interface with Windows time zone identifiers so that TimeZone can interop with Windows system APIs) but this change at least fixes the critical issue and restores the Swift 5.10 behavior, we can look into adding additional API for working with Windows time zone identifiers in the future.
jmschonfeld
commented
1 month ago
The current implementation of
TimeZone.currentattempts to read from/etc/localtimewhich is not a path that exists on Windows. This leads toTimeZone.currentalways being GMT on Windows. Instead, this updates the implementation to callGetTimeZoneInformation, convert the Windows name to an ICU system timezone name, and initialize a timezone with that name (this matches the behavior ofTimeZoneon Swift 5.10 when it was based onCFTimeZone). This also restricts the default values forTZDEFAULT/TZDIRto Darwin + Linux where the paths are reasonable unlike Windows where we know these constants should never exist to avoid accidental usage in the future.There's likely more work to be done here for Windows for a full solution (to allow in some way for developers to interface with Windows time zone identifiers so that
TimeZonecan interop with Windows system APIs) but this change at least fixes the critical issue and restores the Swift 5.10 behavior, we can look into adding additional API for working with Windows time zone identifiers in the future.Resolves https://github.com/swiftlang/swift-foundation/issues/966, rdar://137451317