FW: POSIX-TZ without rules

[Olson, Arthur David (NCI)]

Be sure to direct replies to Guido, who's not on the time zone mailing list.

				--ado

-----Original Message-----
From:	Guido Flohr [SMTP:gufl0000 at stud.uni-sb.de]
Sent:	Monday, April 26, 1999 9:46 PM
To:	arthur_david_olson at 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 at stud.uni-sb.de