[tz] NetBSD vs Darwin timezone API (was: tzdata2016g missing version info)

[Paul Eggert]

On 11/10/2016 02:04 PM, Guy Harris wrote:
>> I don't see an easy way around this problem with the current Darwin API.
> With the current*UNIX*  API.

The NetBSD API gives applications a way to get an immutable time zone 
object, so that multiple operations like localtime_rz and mktime_z can 
use consistent rules. This was originally designed for multithreading 
(so that different threads can be in different time zones) but it also 
has the property that time zone rules don't change once determined 
(which helps performance). Emacs uses this API if available, so Emacs 
should be reasonably immune to these races on NetBSD.

NetBSD doesn't look for changes to the installed tz binary files, as 
Darwin does. If the NetBSD API were implemented atop Darwin, perhaps the 
Darwin tzalloc operation should have a flag specifying whether the 
caller wants the time zone object to be immutable or potentially updated 
after every call.

Come to think of it, perhaps we should add a options arg to the 
reference tzalloc too (for compatibility we'd define a new function like 
tzalloc but with an option arg). One option could be whether the 
implementation should revisit the installed tz binary file every time 
localtime_rz or mktime_z is called (for efficiency perhaps it could use 
file notification on systems where that works well). Another option, 
while we're on the topic, could be whether to count leap seconds. I'll 
CC: this to Christos Zoulas (the NetBSD time guru) to see whether he 
thinks this sort of thing would be a good idea.

> I don't know what Emacs is trying to compute, but perhaps there needs to be an API that atomically gives it what it's trying to compute

Emacs is inferring the daylight-saving rules by making multiple calls to 
localtime. Essentially, Emacs wants a consistent and complete snapshot 
of the current rule set for all times from now into the indefinite 
future. Unfortunately, the API to support this sort of thing would be 
complicated.