RE: Is more detailed timezone history desired?
Top priorities would be: 1. Ensure that the format of the time zone source files is adequate to represent historical changes. 2. Document changes since 1970-01-01 (the POSIX epoch). --ado -----Original Message----- From: Alois Treindl [mailto:alois@astro.ch] Sent: Thursday, March 10, 2005 4:54 PM To: tz@lecserver.nci.nih.gov Subject: Is more detailed timezone history desired? regarding my project to extend the details of timezone history in tzdata, a first question: Is it desirable, in the eyes of current tzdata maintainers, to add such extensions?
Olson, Arthur David (NIH/NCI) wrote:
Top priorities would be: 1. Ensure that the format of the time zone source files is adequate to represent historical changes.
I am confident I can manage the format
2. Document changes since 1970-01-01 (the POSIX epoch).
I think all changes refer to the pre-1970 period. Because I read in the docu that the focus of tzdata is the post-1970 time range, I have asked my question. The large majority of tzdata users might consider such historical detail data to be unnecessary noise, which just blows up the database volume and confuses the innocent Linux installer when a strange number of zones appears as a choice. I admit that probably only astrologers are interested in such details of timezone history. Of course, Thomas Shanks was/is one too. He would not have done his work, otherwise. If I get told that "official" tzdata is not interested in having 50 zones for France, or 15 zones for Germany, I will not get angry. In such a case I will aim for a privately maintained variant of tzdata and not bother you with minority-interest issues.
Alois Treindl <alois@astro.ch> writes:
Because I read in the docu that the focus of tzdata is the post-1970 time range, I have asked my question.
My focus has been on the post-1970 time range mainly because I didn't have the resources to go back before that. POSIX specifies a 1970 cutoff but it's pretty arbitrary. In practice the vast majority of POSIX systems support negative time stamps (for times before 1970), so it would be nice to get things "right" on such hosts (for people who prefer such things).
The large majority of tzdata users might consider such historical detail data to be unnecessary noise, which just blows up the database volume and confuses the innocent Linux installer when a strange number of zones appears as a choice.
That could be addressed by separating the database into a "post-1970-only" version (which is what we have now) and a "complete" version (which would add new zones as needed for regions that differed only before 1970). If done right, it should be easy to derive the former from the latter automatically. Presumably most GNU/Linux users would install only the former. For compatible naming we could call the former "tz" and the latter "tz-complete", or something like that.
On Thu, 10 Mar 2005, Paul Eggert wrote:
Alois Treindl <alois@astro.ch> writes:
Because I read in the docu that the focus of tzdata is the post-1970 time range, I have asked my question.
My focus has been on the post-1970 time range mainly because I didn't have the resources to go back before that. POSIX specifies a 1970 cutoff but it's pretty arbitrary. In practice the vast majority of POSIX systems support negative time stamps (for times before 1970), so it would be nice to get things "right" on such hosts (for people who prefer such things).
Plus the data can be used for other projects. For the Perl DateTime code I maintain, I use the Olson DB files to generate TZ change data as Perl modules. Since I'm not using an epoch-based time representation, the min/max limits on date ranges are much, much bigger than a 32-bit epoch allows. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/
Yes we could put the data into TimesOwn Pro. It is difficult to predict what users want to do with data! Also if it is readily obtainable I think it is a good idea to continue to evolve a central historical repository, as has been occurring anyway. By the way we have a system of time zone change reporting in our software, if we are advised of any Time Zone data changes we will be pleased to pass the information on. Kind regards David Hingston Director Chequers Software Ltd Wellington, New Zealand. http://www.cheqsoft.com support@cheqsoft.com => MathsOwn - World class => Break Reminder - strategic safety software => TimesOwn - the World's best clock => Clipboard Express Pro - drag n drop database saves serious time
participants (5)
-
Alois Treindl -
Dave Rolsky -
Dr Hingston -
Olson, Arthur David (NIH/NCI) -
Paul Eggert