As noted in the previous thread (https://news.ycombinator.com/item?id=13701320), there is no good reason for why libc behaves differently when accessing the default file vs. one explicitly specified by TZ. Whether to stat for changes should be orthogonal to which timezone file is used (or to whether the default is used or not). There should rather be a separate way to configure the stat behavior, assuming it makes sense at all. (I don’t know how many programs can actually properly deal with intermittent changes to the timezone definitions.)
One reply comment of the above link mentions user vs. admin, but that’s not a good argument, because users specifying TZ may still want a long-running background process to observe updates of the timezone file, and also TZ may have been set system-wide rather than by the user.
Sure there's a good reason: if TZ is set, glibc can assume that the timezone is going to be fixed for the duration of the process's life. If it is not set, it will consult /etc/localtime, and will then react to changes in the system timezone.
(Now, when you use TZ=:/etc/localtime, I suppose you could expect that glibc would see that it's a symlink [maybe], and then decide to re-check it each time, but I think the current behavior of not doing that is consistent and sane.)
> glibc can assume that the timezone is going to be fixed for the duration of the process's life.
From what I'm seeing.. it doesn't seem to actually assume that. It does check to see if the TZ name changed between calls and will reload a new tzfile if it has. This same mechanism is what causes the file to be loaded whenever getenv("TZ") returns NULL.
Yes, and if you use setenv(3) to change what the value of TZ is after that point, then the new value of TZ will be observed and the new file will be loaded at that point.
There should rather not be magic stat'ing and loading of random files in a library function that pretends to be stateless.
If it needs to load state from a file to do its thing, it should be split into initialization, the actual operation(s), and cleanup. (You know, like creating, using, and destroying an object, but this is C so this will be explicit calls.)
I wouldn't consider the configuration file that says what the local timezone is a "random file" in the context of a function whose sole purpose it is to convert a timestamp to the local timezone. In fact, loading the file makes the function stateless; because if it didn't, it'd have to cache the timezone somewhere, which can get out of sync with the actual configuration.
Yes, caching would be even worse with no control over the cache's lifetime.
You load the file into memory when I tell you to, you stringify timestamps when I tell you to, using the memory pointer I give you, and you release the memory when I tell you to.
One reply comment of the above link mentions user vs. admin, but that’s not a good argument, because users specifying TZ may still want a long-running background process to observe updates of the timezone file, and also TZ may have been set system-wide rather than by the user.