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".