[tz] Timezone change detection

Paul Eggert eggert at cs.ucla.edu
Sat Sep 4 01:11:36 UTC 2021


On 9/3/21 4:05 PM, Guy Harris wrote:
> Note that, in Darwin, and thus, in macOS/iOS/iPadOS/etc.:
> 
> 	1) there is a notification mechanism by which the code in the OS that adjusts the time zone if the machine (from an iPhone to a MacBook*) crosses tzdb region boundaries can tell all code that uses the time zone information that the time zone has changed;
> 
> 	2) the tzdb-reference-code-based code in libSystem registers for those notifications and reloads the time zone information when the time zone changes;

That shouldn't break zdump. However, it might break an application that 
relies on the system-default timezone rather than on setting TZ 
explicitly, if the application assumes a coherent timezone. That being 
said, if Darwin operates the way you describe it sounds like they're 
willing to live with this sort of breakage. Arguably the benefit is 
worth the cost.

(Does the same thing happen with localtime_r on Darwin? localtime_r is 
documented by POSIX to not necessarily do a tzset, for all the usual 
thread-safety and performance reasons. If localtime responds to these 
notifications but localtime_r does not, this could lead to mysterious 
behavior.)

Edward seemed to be asking for something more, though. That is, he 
appeared to be asking for something where it's also the case that in 
code like this:

    setenv("TZ", "America/New_York", 1);
    time_t x = whatever;
    struct tm a = *localtime(&x);
    struct tm b = *localtime(&x);

A and B might have different values if tzdb is updated between the two 
calls to localtime. This example is independent of whether the system 
default time zone has changed. (And presumably the same thing could 
happen with localtime_r.)

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.

What do you think about all this, Edward?


More information about the tz mailing list