On 0903T1340, Paul Eggert wrote:
On 9/3/21 9:53 AM, Edward Tomasz Napierała via tz wrote:
The use case is to make the applications handle moving between timezones, or changing the default system timezone.
Does the use case include installing new timezone tables when a new tzdb release comes out? Or is it to handle only the case where /etc/timezone changes because the system has moved or has changed its default timezone for other reasons?
The former - it compares both the device/inode numbers, and file modification/change times. It also handles a case where there's a changed symlink in the zone file path.
Won't the change break applications like 'zdump' that call 'localtime' several times and assume that all the 'localtime' calls return consistent values for a single timezone? Perhaps it would be better to do change detection only when tzset is called explicitly; this would be less likely to break zdump etc.
That's a really good point. The mechanism is not compiled in by default, so it is already kind of opt-in, but yeah, I see the problem. I need to think about it some more.
A smaller question: when opening the TZif file for the first time, wouldn't it be more efficient (and avoid a race) to do open+fstat instead of stat+open?
I believe that's how it works right now in FreeBSD version of localtime.c.