Date: Thu, 19 Jul 2018 07:51:28 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <b29fe5b7-1475-f583-dbaf-ca43782bebcf@cs.ucla.edu> | I have my doubts about the version info. I have more than doubts, I am convinced that the entire thing is misguided, and that (with the one exception of curiosity value, the ability of an application to tell people which version data it is using) there is no good use of this data in the way it is being mooted that should not be handled a different way, and that anything using the tzdata version for this (like using the results of that c++ interface that was mentioned) will cause more problems than it can ever solve. To consider the one example that was presented here in the past dat or so - the long running airline application that wants to auto update the tzdata files as needed. That's a reasonable aim. But putting version info in the data is neither needed, nor useful for that. The assumption is that the app can look and see if a new version of the data has appeared, compare with the running version, and update as needed. Fine. But to discover what the new version is cannot be using version info in the data, as that data does not exist yet, only the sources, The app must be using either the version info in the file names, or the version info in the version file. When it updates, it can store that "new" version info anywhere convenient to it, which when the update is done, will become the "version in use" that it can use when looking for the next update to appear. What's more, this is really all part of the packaging system (whether that is something built into the application, or something separate) and not part of the mainstream of the application. Further, depending upon how it is done, putting version info into the data files can be counterproductive, and result in lots of churn. Eg: sometime (probably not too far away) we are going to get 2018f - in that the zone file for Fiji is going to be changed, and anyone who updates to that version will get new data for Fiji, But there is (unless I have forgotten some other pending change) no need for any of the other zone files to alter, and a system might very well detect that, and only update the zones that actually contain different data, rather than all of them, That results in a much more stable system - but if those files contain version info, soon enough there will be many different installed versions. If the version info is to be somewhere else, then the system might just as well install the "version" file somewhere, and use that (assuming it can find a reliable use for it). Longer ago, perhaps the last time this issue came up, or perhaps one of the tmes before that, there was some suggestion that software could automatically update times to account for changes to the zone data. Even assuming this is rational (which I doubt) version info is not needed (or useful) for that - what is wanted is the "old" data, and the "new" data (whatever they call themselves) and the ability to read both, and compare whatever it is needs comparing. For this nothing cares whether the old data is 2018d or 2015c when you're updating to 2018e (nor that the new version is called that) - just that "we used to get this conversion, we now get this other one, which means we should ..." As to the "assuming it s rational" - just go back to the airline example again. We know there is going to be a week when (in Fiji) the old and new tzdata (2018e and 2018f) give different results. But to believe from that the flight times into or out of Suva need to simply be adjusted by an hour would be lunacy. For example, internal flights (within Fiji) will almost certainly continue to operate at the same local wallclock times, which will be an hour earlier (or later, I forget what the change was) in UTC equivalent time for a week than what they would have been. On the other hand, international flights get far more complex - they can't just be moved bty an hour, as that would upset the scheduelling (including gate availability, congestion for takeoff/landing ...) at the other end of the flight, plus not arriving too lage for connecting flights (on other airlines which do not fly to Fiji and have no reason to alter anything), and to deal with airport curfews, etc. It all gets horribly complex, and can't be handled trivially. Of course, the Fiji case is not all that hard, as the new schedule already exists, the only question is which day the switch is made from old to new ... well, almost, there's still a lot of coordination involved, when the "new" means changes that affect operations at other places, and so everything needs to be coordinated. For most other applications, if the correct data is stored, nothing will care if the offsets change (not that nothing will be affected, just that it will all take care of itself) - things only go wrong when apps attempt to short-cut handing of time data, rather than doing it properly. Forget this. - leave version info alone, we have quite enough of it already, and do not need more, and certainly do not need a method for any random application that happens to call localtime() to find out which tzdata version was used. kre