[tz] tzdata2016g missing version information

[Guy Harris]

On Nov 10, 2016, at 1:56 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 11/10/2016 01:20 PM, Guy Harris wrote:
>> For what it's worth, Darwin (macOS, iOS, etc.) will detect at least some time zone changes and the next localtime() call will use the new zone.
> 
> It strikes me that sometimes applications make several calls to localtime()/mktime() and expect the results to be consistent with each other. Emacs, for example, does this to guess time zone rules. These applications won't work if the time zone rules change spontaneously while applications are doing their computation.
> 
> I don't see an easy way around this problem with the current Darwin API.

With the current *UNIX* API.  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, to the extent that, if a change happens in the middle, either it gives correct results for the old time zone or correct results for the new time zone.  If giving the results for the old time zone causes a problem, then there will have to be a way to deliver "time zone changed" notifications to applications *and Emacs will have to handle those notifications*.

There are two issues:

	1) applications running on UN*Xes shouldn't assume that the time zone won't change - there exists at least one UNIX(R) where it *can* change out from under you, and there may be more UN*Xes where it does or where it will on future versions;

	2) applications that need more information about time zones than "what's the local time for this seconds-since-the-Epoch value" or "what's the seconds-since-the-Epoch value for this local time, if there is such a value?" may require new APIs.