I recommend adding the date of the change to the data files. The africa data file for example only has the following at the top of the file: # @(#)africa 7.33 The other data files also lack the date. I don't think that the file date in the tar files can be depended on to be the date of a change - I know for sure that some of the files in the March distribution have not been changed for a while. The pacificnew file has a time tag of Mar 14 09:39 but is no different from the file I have been using since October 1998. -- Martin Smoot Network Storage Solutions 703-834-2242 msmoot@nssolutions.com www.nssolutions.com
Martin Smoot wrote on 2000-07-28 15:39 UTC:
I recommend adding the date of the change to the data files. The africa data file for example only has the following at the top of the file:
# @(#)africa 7.33
The other data files also lack the date.
I recommend to use RCS for revision control, which is today the de-facto standard, and supports even trendy ISO 8601 dates and UTC timestamps. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
On Fri, 28 Jul 2000, Markus Kuhn wrote:
I recommend to use RCS for revision control, which is today the de-facto standard, and supports even trendy ISO 8601 dates and UTC timestamps.
How about CVS, with an anoncvs server and so on? There are services such as sourceforge.net providing CVS servers. And it should be possible to convert the existing revision control history. -- Joseph S. Myers jsm28@cam.ac.uk
Markus Kuhn wrote:
Martin Smoot wrote on 2000-07-28 15:39 UTC:
I recommend adding the date of the change to the data files. The africa data file for example only has the following at the top of the file:
# @(#)africa 7.33
The other data files also lack the date.
I recommend to use RCS for revision control, which is today the de-facto standard, and supports even trendy ISO 8601 dates and UTC timestamps.
Markus
-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
"Joseph S. Myers" wrote:
On Fri, 28 Jul 2000, Markus Kuhn wrote:
I recommend to use RCS for revision control, which is today the de-facto standard, and supports even trendy ISO 8601 dates and UTC timestamps.
How about CVS, with an anoncvs server and so on?
There are services such as sourceforge.net providing CVS servers. And it should be possible to convert the existing revision control history.
-- Joseph S. Myers jsm28@cam.ac.uk
I think an automated method is the way to go too. One possible problem I can see with using an automated revision control system of any sort is that when the files are checked into yet another revision control system, the version number and date may be changed. we use CVS for our development and when the new timeline data files are downloaded and verified, we check them into our CVS repository. If the version number in the file is tagged so that CVS recognizes it, it gets changed to our current version number (1.5 for example) and date. as of now, the current version information is not touched by CVS when the files are checked in. There is probably a way with these systems to make the checkin use something other then $Log or $Id for the revision line (not obvious looking at man pages for cvs/rcs). If that is possible, they could be tagged with something like $TZ so that end users of the file do not have to worry about "trashing" the revision data. -- Martin Smoot Network Storage Solutions 703-834-2242 msmoot@nssolutions.com www.nssolutions.com
Date: Fri, 28 Jul 2000 11:39:14 -0400 From: Martin Smoot <msmoot@nssolutions.com> I don't think that the file date in the tar files can be depended on to be the date of a change One should be able to depend on them. (After all, we're the ones that are supposed to be meticulous about time stamps. :-) I noticed the file-date problem myself, and have been repairing the file dates as I get them, but it would be nicer if the file dates were correct in the distributed tar file. Here's a shell script to repair the time stamps of the tz source files to be what I think are the correct values. You can apply this script after extracting the files from tzcode2000d.tar.gz and tzdata2000d.tar.gz. Perhaps this time-stamp repair could be done to the master copy of the files, before the next version is generated? Of course any files changed after 2000d should have newer time stamps. TZ=UTC0 export TZ touch -t 200003041531.07 africa touch -t 200002211706.16 antarctica touch -t 199805281356.06 asctime.c touch -t 200003041531.07 asia touch -t 200003041531.07 australasia touch -t 200001181421.21 backward touch -t 199911081955.21 checktab.awk touch -t 199712291431.49 date.1 touch -t 200004201942.55 date.c touch -t 199606051202.02 difftime.c touch -t 199808110316.33 etcetera touch -t 200003141438.50 europe touch -t 199712182247.23 factory touch -t 199909231348.14 gccdiffs touch -t 199703072106.34 ialloc.c touch -t 199911081955.18 iso3166.tab touch -t 199908171809.08 leapseconds touch -t 199909231346.39 localtime.c touch -t 199601102150.25 logwtmp.c touch -t 200004190501.31 Makefile touch -t 199705032252.21 newctime.3 touch -t 200004201942.50 newstrftime.3 touch -t 199705032252.21 newtzset.3 touch -t 200003041531.08 northamerica touch -t 199712111744.34 pacificnew touch -t 200004190501.31 private.h touch -t 199709042055.54 README touch -t 199707191714.53 scheck.c touch -t 199510301507.11 solar87 touch -t 199510301507.11 solar88 touch -t 199603190149.39 solar89 touch -t 200003041531.08 southamerica touch -t 200004201942.56 strftime.c touch -t 199311222023.15 systemv touch -t 200002211709.29 Theory touch -t 199712291431.51 time2posix.3 touch -t 200004201943.03 tz-art.htm touch -t 200003041531.09 tz-link.htm touch -t 199802281732.26 tzfile.5 touch -t 199712291431.51 tzfile.h touch -t 199909231346.31 tzselect.8 touch -t 199909231347.28 tzselect.ksh touch -t 199611051850.18 usno1988 touch -t 199611051850.18 usno1989 touch -t 199611051850.18 usno1989a touch -t 199512211745.53 usno1995 touch -t 199909231348.12 usno1997 touch -t 199805281356.24 usno1998 touch -t 199509012121.36 yearistype.sh touch -t 199605030252.35 zdump.8 touch -t 199901192120.08 zdump.c touch -t 199911131942.59 zic.8 touch -t 199908171809.09 zic.c touch -t 200001181421.22 zone.tab
participants (4)
-
Joseph S. Myers -
Markus Kuhn -
Martin Smoot -
Paul Eggert