3 ms·
Offhand, and a quick google search; I was unable to find the exact definition / specification for how time-zone data must be obtained rather than how it happens
by mjevans 3y ago
Offhand, and a quick google search; I was unable to find the exact definition / specification for how time-zone data must be obtained rather than how it happens to conventionally be obtained.
It is entirely reasonable that any of the following _might_ be valid behavior.
* Simple but syscall heavy approach which re-reads the env, and possibly /etc/localtime each call and has no stability. (Results may mutate as other processes / threads change things.)
* Same as above, then caches the decision result for some application specific reasonable time; which may be until the application exits.
* The elsewhere mentioned stat / inotify approaches that only track updates to /etc/localtime (and ideally update the cached decision result when notified).
All approaches seem valid. It's sort of like the hostname or any other system level configuration where a reboot may be a reasonable expectation for a complete update.
- lifthrasiir 3y agoThat was also my thought. To my knowledge `/etc/localtime` is the creation of Arthur David Olson, the founder of the tz database (now maintained by IANA), but his code never read `/etc/localtime` multiple times unless `TZ` environment variable was changed. Tzcode made into glibc but Ulrich Drepper changed it to not cache `/etc/localtime` when `TZ` is unset [1]; I wasn't able to locate the exact rationale, given that the commit was very ancient (1996-12) and no mailing list archive is available for this time period. [1] https://github.com/bminor/glibc/commit/68dbb3a69e78e24a778c6602c8cc91d715839d08#diff-680a4b70a0fc1a41c25225534c76b25bd0861a198141b0f2635f13a2b6fa9de8 https://github.com/bminor/glibc/commit/68dbb3a69e78e24a778c6...