Be sure to direct replies to Guido, who's not on the time zone mailing list. --ado -----Original Message----- From: Guido Flohr [SMTP:gufl0000@stud.uni-sb.de] Sent: Monday, April 26, 1999 9:46 PM To: arthur_david_olson@nih.gov Subject: POSIX-TZ without rules Hello! I'm the current maintainer of the MiNTLib. The MiNTLib is the standard libc for MiNT and MiNT is a free Unix-clone for Atari computers. I've implemented parts of the tzcode and tzdata packages (version 1998c) in the MiNTLib. This went mostly without problems. Two problems arised: First, for testing purposes I set the envariable TZ to "CET-1CEST-2", i. e. a valid POSIX-style string but without explicit rules. I also uninstalled the database for that test. Under these circumstances tzparse() in localtime.c will return an error because it fails to open a default rules file. From what I remember I would say that POSIX demands that the US rules should be applied instead. Anyway, "CET-1CEST-2" is perfectly POSIX-compliant and the library should not return an error then. The GNU libc handles this case by assuming an implicit rule of "M4.1.0,M10.5.0" (commented as "US Federal Law"). My solution is somewhat different: I generated a header "new_york.h" with the disassembled contents of /usr/share/zoneinfo/posix/America/New_York. Now, not giving rules with no time zone database installed has the same effect as linking posixrules to America/New_York (as recommended in the Makefile of tzcode). The second problem: In zic.c, the analysis of the return value of system("yearistype ...") assumes a certain structure of that return value. I think it would be more portable to use the macros from sys/wait.h instead (although this would probably require an additional -D option to cc that determines whether to use POSIX- or BSD-style macros). May sound pedantic, but here's the story: I have happened to introduce a bug in the waitpid() function of the MiNTLib; the upper two bytes of the status pointer weren't zeroed out but contained some garbage. This affected system() because it calls waitpid. The error message from zic was: wild result 27525120 ... australasia line 75, command was "./yearistype 1990 even" Well, I could figure out what happened, but an average user would have had problems, because typing the command literally into the shell simply returned 0. If I understand the sources correctly, the more common error that the yearistype command is not found (e. g. running "zic -y yearistype ..." without "." in $PATH) would also produce quite confusing error messages (but at least the shell would also complain because you don't redirect stderr to /dev/null). Another argument: The specification for system() explicitely demands to use the wait macros to analyse the return value. These macros would have worked in the above described case. From this point of view the garbage in the upper 2 bytes is not even a bug. Apart from that: Thanks for all the work you must have invested into the time zone database! Everything works perfectly fine here. Ciao Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de