chronotope / chrono

Date and time library for Rust
Other
3.28k stars 518 forks source link

Improve support for illumos and Solaris #1252

Open pitdicker opened 1 year ago

pitdicker commented 1 year ago

There are several very informative comments in the time-rs repo. From https://github.com/time-rs/time/pull/543#issuecomment-1405963381:

The illumos implementations of tzset(3C), localtime_r(3C), setenv(3C), and getenv(3C), all have an MT-Level of Safe or MT-Safe; MT-Level and other attributes are described in attributes(7). We inherited them a decade ago when we forked from Solaris, so I would expect that Solaris is also thread safe for all of these routines.

In addition to thread safety, our time zone configuration is a bit different from a Linux system, though most of this is hidden from a consuming process behind the standard entrypoints like localtime_r(), etc.

A process determines the local time zone in roughly this way:

  • if TZ is set in the environment, we'll use it uncritically to select the zone
  • if TZ is not set, we'll read the TIMEZONE(5) file: a text file which is allowed to contain a TZ= line specifying the time zone
  • otherwise, we'll default to GMT0

Iff a process does not have TZ set in its environment, we cache the value read from /etc/TIMEZONE the first time we try to establish a local time, and the zone information from the zoneinfo file. This cache can be purged in all processes on the system by a privileged user with the tzreload(8) command. One can, thus, reconfigure the local system time zone while software is running. If a process does have TZ set in its environment then tzreload won't change the time zone for that process, but it will still invalidate the cache of the nominated zone file, which might have been patched in a package update to reflect an updated set of time zone information without needing to restart all the software on the system.

Historically systems like Java and Go and so on have created challenges for operators by ignoring the local time zone database, or at least some of the system facilities for configuring and refreshing it. It would be really great if we could avoid having that happen with Rust, where there are truly superlative facilities for using system library routines through FFI, etc!

pitdicker commented 1 year ago

We don't support the /etc/TIMEZONE file on illumos and Solaris yet, or the invalidation mechanism.

Kijewski commented 8 months ago

Evaluating /etc/TIMEZONE is implemented in iana-time-zone: tz_illumos.rs

djc commented 8 months ago

Let's wait for someone who has an actual Illumos/Solaris use case to implement this.