Another issue would be using tzdb extensions taken from NetBSD:
timezone_t tz = tzalloc("America/New_York"); time_t x = whatever; struct tm a = *localtime_rz(tz, &x, &a); struct tm b = *localtime_rz(tz, &x, &b);
A and B might have different values if tzdb is updated between the two calls to localtime_rz. Even though tz is a time zone "value", it is a "value" that mutates when tzdb is updated. This usage appears to be particularly problematic, as part of the point of localtime_rz is speed and thread-safety, and I'd hate for it to have to consult the filesystem.
I don't think this is right. tzalloc() loads the zone data and after that the filesystem is not consulted anymore, so A and B will always be the same. In fact, I would say that the tzalloc() mechanism should be used for applications that wish to use fresh data each time the timezone file gets updated. 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). christos