Changes to the system time zone are not visible in macOS

[kathoum]

In macOS, if the system time zone changes while the current process is running, get_timezone() returns the previous time zone instead of the current time zone.

Reproduction

Run the following program:

fn main() {
  loop {
    println!("{}", iana_time_zone::get_timezone().unwrap());
    std::thread::sleep(std::time::Duration::from_secs(2));
  }
}

While the program is running, change the system time zone (from the Settings UI or using sudo systemsetup -settimezone).

In MacOS, the programs keeps printing the old time zone.
In Windows and in Linux, the program output reflects the change in system settings.

Proposed fix

diff --git a/src/tz_macos.rs b/src/tz_macos.rs
index 70c39e8..a90aced 100644
--- a/src/tz_macos.rs
+++ b/src/tz_macos.rs
@@ -32,7 +32,9 @@ mod system_time_zone {
     //! create a safe wrapper around `CFTimeZoneRef`
 
     use core_foundation_sys::base::{CFRelease, CFTypeRef};
-    use core_foundation_sys::timezone::{CFTimeZoneCopySystem, CFTimeZoneGetName, CFTimeZoneRef};
+    use core_foundation_sys::timezone::{CFTimeZoneCopySystem, CFTimeZoneGetName, CFTimeZoneRef, CFTimeZoneResetSystem};
 
     pub(crate) struct SystemTimeZone(CFTimeZoneRef);
 
@@ -46,7 +48,10 @@ mod system_time_zone {
     impl SystemTimeZone {
         pub(crate) fn new() -> Option<Self> {
             // SAFETY: No invariants to uphold. We'll release the pointer when we don't need it anymore.
-            let v: CFTimeZoneRef = unsafe { CFTimeZoneCopySystem() };
+            let v: CFTimeZoneRef = unsafe {
+                CFTimeZoneResetSystem();
+                CFTimeZoneCopySystem()
+            };
             if v.is_null() {
                 None
             } else {

[lopopolo]

It seems most idiomatic for iOS and macOS apps to use NSNotificationCenter and listen for NSSystemTimeZoneDidChangeNotification to trigger a call to CFTimeZoneResetSystem.

This crate intentionally only binds to CoreFoundation and it seems inappropriate to automatically set up an event handler in this low level library.

Additionally, it doesn't feel great to intentionally subvert the caching put in place by CoreFoundation.

Can you provide more context on the problem you're trying to solve and why invalidating the cache in some other way is not appropriate? Why do we need to add this logic in iana-time-zone crate?

[lopopolo]

Thanks for raising this bit of nuance! My inclination is to not accept this proposed diff and to instead add some platform specific caveats to the docs for iOS, macOS, and tvOS.

[Kijewski]

Maybe the NSSystemTimeZoneDidChangeNotification listener could be implemented in its own crate that could be pulled in with a feature flag?

It looks like reading an uncached timezone value could be quite time consuming: CFTimeZone.c. (The file mixes tabs and spaces for indentation, which is not displayed properly in github.)

[kathoum]

I noticed this while debugging a service that checks the current timezone when some event happens; since the caching behaviour is different from the other platforms I tested on, I thought it was not intentional. In my case there are no performance concerns, so I can add a call to CFTimeZoneResetSystem to invalidate the cache just before calling the function.

If caching is expected on Apple platforms, I agree with your proposal to document the platform-specific bits.