- tz - lists.iana.org

problem withzic 7.81 (1997a)
by Dave Sparks March 2, 1997

March 2, 1997

I recently downloaded tz{code,data}1997a.tar.gz in order to update our timezone database. Because we will not be using any dates earlier than 1970 I used zic -s to save space. All the timezone information was compiled, but when I tried to install the data into our database four timezones failed the sanity checks. I found that the compiled files for these timezones were each 44 bytes long and contained only zeros. The zones were: Australia/Darwin Africa/Accra Africa/Freetown Africa/Johannesburg (none of which have transitions after 1970). I looked at zic.c and made the following changes: 207% diff zic.c zic.OLD.c 3c3 < static char elsieid[] = "@(#)zic.c 7.81 +DaveS"; --- > static char elsieid[] = "@(#)zic.c 7.81"; 1572a1573 > usestart = i > 0 && (zp - 1)->z_untiltime > min_time; 1576d1576 < usestart = (timecnt == 0 && !useuntil) || (i > 0 && ((zp - 1)->z_untiltime > min_time)); which was partially successful (the Australian timezone was handled, but the African timezones needed modifications which wouldn't have been necessary if the fix had been correct: 208% diff africa africa.OLD 325,326c325 < 0:00 Ghana %s 1942 < 0:00 - WAT --- > 0:00 Ghana %s 561,562c560 < 0:00 SL WA%sT 1962 < 0:00 - WAT --- > 0:00 SL WA%sT 581,582c579 < 2:00 SA SA%sT 1944 < 2:00 - SAT --- > 2:00 SA SA%sT ). After looking more carefully at the timezone data, I realised that what the troublesome timezones had in common wasn't just that there were no transitions after 1970, but also that the last transition was by Rule. Since by then I had compiled data which we could use, I didn't look at zic.c again to try to work out a better fix. Incidentally, the assumption that the first Standard Time offset should be used for times before the first transition doesn't work well for Southern Hemisphere timezones: in many cases Summer Time will be in effect at the earliest time handled. (In case you were wondering why we need to import the timezone data into our own database: the application in question has to handle multiple timezones and is nor written in C or C++.) -- Dave Sparks, Staffordshire, England (posted from my private mailbox to avoid my employer being legally liable, since in English law a disclaimer would be ineffective.)

1 0

Re: ISO 8601 revision
by kuhn＠cs.purdue.edu March 1, 1997

March 1, 1997

Keld J|rn Simonsen wrote on 1997-03-01 22:50 UTC: [How do we get in contact with the ISO 8601 working group?] > I can try to ask the Danish Standards people. Great! > Have you got any suggestions for the "ugly T"? [Anyone interested in this discussion without a copy of ISO 8601, please download and print first <ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z> for reference.] I think, a space is the nicest solution as in 1997-03-01 22:50 and it should definitely be explicitely allowed. The current standard gave the author of <http://www.internic.net/internet-drafts/draft-newman-datetime-01.txt> the impression that the "ugly T" is the only comforming way of writing down both date and time, which is the only reason why the new proposed Internet standard date and time format (an ISO 8601 profile) has the "T". Only for applications, where a space is inconvenient (e.g, Unix command line options, where fields are separated by space), the hyphen as used in the corresponding ANSI standard and as shown in the "Chicago Manual of Style" is also quite nice: 1997-02-28-22:50 I do not see, where this overloading of the hyphen would cause problems with the requirement, that a parser must be able to distinguish all formats. If it causes problems with unambiguous parsability, then I wouldn't mind dropping some of the less useful notations from the ensemble. I also find the notation "--MM-DD" awfull for cases where I do not specify the year as it follows from context. It would be much nicer if notations like "-MM-DD" and "-DD" would be part of the collection, as this would allow to use these notations in sentences like "The conference will take place from 1997-08-28 to -31, and the tutorial sessions will run from -08-28 to -09-05." Instead these patterns are currently used for "-YY" and "-YY-MM". I think, using the leading hyphen to indicate the missing century digits was a bad idea. Please note that although ISO 8601 was intended as a standard for data respresentation, it is today quoted in standards for business letter typographical conventions (e.g., DIN 5008-1996). ISO 8601 currently lists numerous incomplete formats which I strongly doubt will ever be used anywhere (e.g., "---DD"). They are in applications like Unix cron, where you want to specify periodic events, much better represented by a more generic extended wildcard notation that allows to specify events like the last Sunday of every month, something ISO 8601 currently does not yet provide. Useful new notations might be 1997-100.5 (noon of the 100th day of 1997) 1997-02-3-7 (the third sunday of February 1997, especially useful with unspecified year or year/month as in *-3-7 or *-02-3-7) These are just a few first ideas for improvement. Once we get in contact with the working group and hear about their plans, we can start working on a detailed proposal. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

tzcode1997b.tar.gz and tzdata1997b.tar.gz
by ado Feb. 27, 1997

Feb. 27, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997b.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997b.tar.gz are now available. The data file incorporates the 1997 leap second; the code file incorporates your correspondent's take on the zic/multiprocessor/directory-creation situation. --ado

1 0

Re: 8th EU Directive, French time
by peter＠memex.co.uk Feb. 27, 1997

Feb. 27, 1997

> Has the 8th EU Summer Time Directive come out? (starting in 1998) Not that I know of. The Transport Council (the group of national transport ministers who decide this) aren't due to meet for the first time this year until 11 March so I can't see it happening before then. I have just checked with my contact at the local EC Information Office and she hasn't heard anything either. They did apparently have an informal meeting on 31 Jan but I can't see anything in the midday press releases (at http://europa.eu.int/en/comm/spp/me/midday.html, with the relevent past ones at me970131.html, me970203.html, etc. (these people have a year 2000 problem looming :-) ). > Also, is France going to move from GMT+1 to GMT+2 this spring, and are they > still discussing remaining on the same time all year? (Perhaps permanent rule > change might be deferred until the end of the 7th Directive in October 1997.) I haven't seen any reports about this for months. I think it very unlikely that they will not follow the existing 7th directive. Any change, if it comes at all, is likely to be in 1998. > Has a date been set for the British General Election? No, but the options are closing in all the time. John Major has all but said it will be 1 May. I think the latest date is 5 May, but elections are always on a Thursday here so that is out. The other hot tip was 20 March but I think it is now too late to dissolve Parliament and meet that date. There is a by-election at Wirral South today, the result of which will no doubt confuse things even more. A bit of bonus news I saw today: there will be a leap second on 30 June 1997. See ftp://hpvlbi.obspm.fr/iers/bul/bulc/bulletinc.13 or http://tycho.usno.navy.mil/leap.html. Peter Ilieve peter(a)aldie.co.uk

2 1

8th EU Directive, French time
by Chris Carrier Feb. 27, 1997

Feb. 27, 1997

Some questions for our UK/European correspondents: Has the 8th EU Summer Time Directive come out? (starting in 1998) Also, is France going to move from GMT+1 to GMT+2 this spring, and are they still discussing remaining on the same time all year? (Perhaps permanent rule change might be deferred until the end of the 7th Directive in October 1997.) Has a date been set for the British General Election? Thank you. Chris Carrier

3 2

Interest in Timezone Information at JPL
by Dave Skinner Feb. 26, 1997

Feb. 26, 1997

I guess I should be added to at least the tz-requests mailing list and possibly the tz mailing list as well if it does NOT include the former email addresses by default. I represent the only person at the Jet Propulsion Laboratory who has both an abiding interest in these matters as well as an immediate and on-going need for this information. For the record, I am coding a web-based capability to look up the latitude and longitude of any any geographic name that is being maintained in the http://www.nima.mil/gns/html/index.html web site, which is the National Imagery and Mapping Agency (NIMA) GEOnet Names Server for non-US geographic names, and at the http://www.census.gov/cgi-bin/gazetteer web site of the US Census Bureau, which is the name server for US geographic names. Once, I have the laititude and longitude I am currently planning to find out which of your timezones is the timezone associated with either the country or territory involved or, if the country in question has multiple timezones, to ascertain which of these timezones is the correct one based on the associated latitude and longitude. Finally, I plan to maintain and use your timezone information to find the best estimate of time-of-day at that location for a specified julian date. I say "best estimate" because many of our lookups will necessarily be for future events, and the timezone boundaries, their associated offsets from GMT, and especially their associated daylight savings time rules are obviously only as good as we know them today. The only problem that remains to be solved is the polygon information that is currently burried in the http://www.odci.gov/cia/publications/95fact/802389h.gif file. To automatically lookup which timezone is associated with a given latitude and longitude requires having those polygons. So, I plan to see if the CIA Publications types would be willing to post such a file. If not, I may be forced to beat on the gif file. Anyway, it is really great to see that such a thorough effort to identify and maintain timezone information is occurring. Dave Skinner dave(a)kirdu.jpl.nasa.gov

1 0

"tzcode.tar.gz" and "tzdata.tar.gz" as links?
by guy＠netapp.com Feb. 11, 1997

Feb. 11, 1997

I sometimes suggest, in postings and mail messages, that people should pick up the Olson code and database; unfortunately, I have to put it as, e.g.: The [Arthur] Olson code, available, to those with FTP access, from "elsie.nci.nih.gov", in "pub/tzcode1997a.tar.gz" (unless, by the time you see this posting, Arthur's put out another version, in which case it'll be "1997b" or something such as that), ... (to quote a recent "comp.unix.solaris" posting). "libpcap" and "tcpdump", for example, handle this by having "libpcap.tar.Z" being a symlink to the current version of the "libpcap" library, and having "tcpdump.tar.Z" being a symlink to the current version of "tcpdump"; should something similar be done for the "tzcode" and "tzdata" "tar.gz" files?

1 0

your timezone program.
by Igor Grobman Feb. 5, 1997

Feb. 5, 1997

-----BEGIN PGP SIGNED MESSAGE----- Hi, I am one of the developers of Debian Linux, a popular free Linux distribution. I was asked to fix bugs in this program that were filed by our users in the bug tracking system. The most serious bug is "the missing timezones". Apparently, your program included some timezones in an earlier version (I would guess around 1994) that were later dropped. The zones that users most ask about is something like US/Eastern, /US/Central, /US/Western, and similar things for other countries. I understand you probably don't want to release an official version with these zones defined, but what would be the best way for me to do it in order to fix it in the distribution? I looked at the source, and saw that you already use "Link" to link some of the obsolete zones. Would it be wise to link those old zones to the corresponding new timezone? Thanks. __ Proudly running Debian Linux! Linux vs. Windows is a no-Win situation.... Igor Grobman igor(a)vaca.net -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQBVAwUBMvkDmf6MRr9c8VylAQFtewIAnXYYWwxzoC9erTAgnUJrldkiNQKS//63 cwtOUOY1y1XMAPduspYjmezHMGq47UW1bRgowr+nl9IWzPHqfhU3gA== =iHGm -----END PGP SIGNATURE-----

1 0

Re: zic on multi-processor systems
by Ulrich Drepper Feb. 3, 1997

Feb. 3, 1997

Ken Pizzini <ken(a)halcyon.com> writes: > if (!itsdir(name)) { > /* > ** It doesn't seem to exist, so we try to create it. > + ** Double check the return. Someone may be one > + ** step ahead of us. > */ > if (mkdir(name, 0755) != 0) { > + int sverr = errno; > + if (!itsdir(name)) { > const char *e = strerror(errno); You probably mean `sverr' here --------------------------^^^^^ BTW: I would change the if line to if (errno == EEXIST && !itsdir(name)) I've sent the patch as I got it and thought about it only later. Thanks, -- Uli ---------------. drepper(a)cygnus.com ,-. Rubensstrasse 5 Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany Cygnus Solutions `--' drepper(a)gnu.ai.mit.edu `------------------------

1 0

zic on multi-processor systems
by Ulrich Drepper Feb. 2, 1997

Feb. 2, 1997

Hi, the following patch will improve the usability of zic in environments with multiple processors (or make running several processes). We are in this situation in GNU libc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff -u gnu/glibc/time/zic.c:1.1.1.4 gnu/glibc/time/zic.c:1.2 --- gnu/glibc/time/zic.c:1.1.1.4 Wed Jan 22 06:58:14 1997 +++ gnu/glibc/time/zic.c Sun Feb 2 12:02:29 1997 @@ -2126,8 +2126,11 @@ if (!itsdir(name)) { /* ** It doesn't seem to exist, so we try to create it. + ** Double check the return. Someone may be one + ** step ahead of us. */ - if (mkdir(name, 0755) != 0) { + if (mkdir(name, 0755) != 0 && !itsdir(name)) + { const char *e = strerror(errno); (void) fprintf(stderr, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, -- Uli ---------------. drepper(a)cygnus.com ,-. Rubensstrasse 5 Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany Cygnus Solutions `--' drepper(a)gnu.ai.mit.edu `------------------------

2 1