[tz] Timezone change detection

[Paul Eggert]

On 9/4/21 2:05 AM, Christos Zoulas wrote:
> Perhaps we should add a  "const char *tzgetpath(const timezone_t);" so that the application can use whatever mechanism it wants to detect staleness (but that would require adding more information to timezone_t). If we want to implement staleness checks in the library, we should do this by adding the information to detect staleness in timezone_t, not using static variables (which are also not thread safe, and don't work with the "z" variants).

The approach I had thought of would be to add a tzalloc variant in which 
you specify a flag saying "I want this timezone_t to be updated if the 
system changes timezone or timezone data". Using that flag would slow 
down localtime_rz calls that use the resulting timezone_t. There might 
be multiple flags depending on how much checking you want.

This approach would insulate apps from the details of staleness 
checking. It'd allow the implementation to go to a Google-like approach, 
for example, where there's just one big file with all the TZif data 
inside it.

This approach would affect only the relatively few apps that use 
localtime_rz, though. For apps using localtime and localtime_r, surely 
it'd be OK for us to change tzset so that it always checks the 
filesystem (which it doesn't always do now), and to make this change 
only for explicit calls to tzset. That wouldn't break many applications, 
as nobody expects localtime results to be consistent across explicit 
tzset boundaries.

As for localtime routinely checking a la Darwin, that's problematic for 
the semantic reasons already discussed. If we do that, I suspect we 
should do it only if a build-time option tells us to. And perhaps we'd 
need two options, one for "look for changes to the sysadmin's selection 
of the default timezone", and one for "look for changes to the database".