On Sep 4, 2021, at 9:25 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
As for localtime routinely checking a la Darwin, that's problematic for the semantic reasons already discussed.
Note that at least one trademark-licensed UNIX implements that approach (albeit with a notification mechanism rather than polling i.e. routinely checking); it's unwise for UN*X programs to assume that the timezone doesn't change out from under you, especially given that there are UN*X devices that you can wear on your wrist even if you're riding in a vehicle that can cross time zone boundaries. According to C11, "The local time zone and Daylight Saving Time are implementation-defined.", so I don't see anything there that forbids the local time zone from changing out from under the program. The tzset() page in the Single UNIX Specification says The tzset() function shall use the value of the environment variable TZ to set time conversion information used by ctime, localtime, mktime, and strftime. If TZ is absent from the environment, implementation-defined default timezone information shall be used. Which also doesn't appear to forbid the local time zone from changing out from under the program if TZ isn't set. So it may be "problematic" but my sympathies for any software for which that causes problems is limited. I don't object to making something such as that not be the default, but I'll still advise software developers either to explicitly set TZ or to use localtime_rz() if they need to convert times in a specific fixed time zone. (I'd *love* to have localtime_rz(), or some equivalent, available within Wireshark, on multiple platforms including Windows, for example, so people who want to see packet time stamps etc. in the zone in which they were captured could do so without annoying and platform-dependent hacks.)