Setting the time zone via the TZ variable has no effect

[teythoon]

On POSIX systems, the timezone can be overridden on a per-process basis by setting the TZ environment variable:

• https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
• https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Unfortunately, this has no effect on this crate.

[astraw]

What platform are you on? How do you test this? On my PC:

andrew@pc iana-time-zone % cargo build --example get_timezone        
   Compiling iana-time-zone v0.1.57 (/Users/andrew/Documents/src/iana-time-zone)
    Finished dev [unoptimized + debuginfo] target(s) in 3.16s
andrew@pc iana-time-zone % target/debug/examples/get_timezone  
Europe/Berlin
andrew@pc iana-time-zone % TZ=EDT target/debug/examples/get_timezone 
America/New_York

[teythoon]

I'm on Debian/Linux, mostly Bookworm (i.e. current stable):

% target/debug/examples/get_timezone
Europe/Berlin
% TZ=EDT target/debug/examples/get_timezone
Europe/Berlin
% TZ=Africa/Nairobi target/debug/examples/get_timezone
Europe/Berlin
% TZ=:Africa/Nairobi target/debug/examples/get_timezone
Europe/Berlin

[astraw]

This crate developed organically and had no unifying concept behind handling the TZ environment variable. So thanks for bringing this up. I have now dug into this a bit.

According to the POSIX specification, there are two options for the TZ environment variable. First is :characters, which is handled in an "implementation-defined" manner. Second is a time zone rule literal, which defines the (bidirectional) mapping between Universal Time and the user's local time. We cannot convert a rule literal into an IANA time zone, so it seems there's nothing we can do there and I don't consider it further here. So, let's focus on the "implementation-defined" situation like TZ=:Africa/Nairobi.

It seems glibc, musl, Android, and macOS (at least) all follow a similar convention in which the local IANA time zone can be specified in the TZ environment variable:

• glibc: https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
• musl: https://musl.libc.org/doc/1.1.24/manual.html
• Android: https://android.googlesource.com/platform/bionic/+/gingerbread-release/libc/docs/OVERVIEW.TXT#79
• macOS: I could not find official documentation for the use of the TZ variable (e.g. here)

In current behavior of this crate is as follows. On some platforms (e.g. macOS) we use a function call to a system library to get the time zone name for us. In the case of macOS, this will handle the TZ environment variable for us (although see below). In the case of linux, we examine the /etc/localtime symlink as our default first step and then try /etc/timezone as a first fallback.

Should we handle the TZ environment variable uniformly across platforms (potentially deviating from platform-standard behavior), or we should handle TZ on a per-platform basis? Or should we keep the status quo?

Other notes:

In testing, I found that in macOS 13.5.1, the function CFTimeZoneCopySystem -- which we use -- handles TZ=Africa/Nairobi (no :) to set the time zone to Nairobi but TZ=:Africa/Nairobi (with :) is ignored. (For the case with no :, this seems in contradiction to POSIX as thus should be a rule literal.) However, /bin/date in macOS handles TZ with and without : to set the time zone. In glibc, the localtime function defined in time.h handles both TZ=:Africa/Nairobi and TZ=Africa/Nairobi to set the time zone to Nairobi. So, setting TZ to the time zone with no : is handled the same by macOS and glibc (although contradictory to POSIX).

Apparently C++20 has added std::chrono::current_zone()->name() which will return the IANA time zone name: https://stackoverflow.com/a/37992725

I have not yet attempted to figure out what Windows does with the TZ environment variable. I did find this https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-170.

[teythoon]

I concur with your analysis. Personally, I think this crate should strive for consistency with the platform, so that applications built on top of it behave like "native" applications, i.e. avoid surprising the user.

[lopopolo]

Hey folks, can y'all help me understand how making this behavior change would not be the same as reintroducing https://rustsec.org/advisories/RUSTSEC-2020-0159.html to the ecosystem?

[astraw]

@lopopolo I think if we use rust's std to get the environment variable, we should be OK (see time-rs/time#293 (comment)). That said, I'm not an expert in this.