On Thu, Apr 29, 1999 at 04:39:29PM -0700, Paul Eggert wrote:
From: Guido Flohr [SMTP:gufl0000@stud.uni-sb.de] Sent: Monday, April 26, 1999 9:46 PM
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.
POSIX.1 is not US-centric here; it says that the behavior in this case is implementation-defined. The rationale (POSIX 1003.1-1996 section B.8.1.1 page 493 lines 5609-5612) says ``An implementation may provide those rules [i.e. the DST rules not explicitly specified by the user]
OK, I'll never use the word POSIX again. ;-) My information is only second hand.
Anyway, "CET-1CEST-2" is perfectly POSIX-compliant and the library should not return an error then.
Yes. My reading of POSIX.1 is that the implementation is allowed to guess the DST rules, but it's not allowed to fail.
I agree. A popular German Unix guide recommends "CET-1CEST-2" as the default TZ setting for Germany, German HP-UX distributions use it to (well, with "MET" instead of "CET").
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"
Both solutions have problems. The first mishandles old dates; the second assumes the New York City DST rules, whereas it'd be better to assume only the US rules. Implementing the plain US rules (back to 1918) would be better; can you do this?
Do you mean writing a rules file for that case (which could be compiled and hardcoded into the library)? Actually I even have problems with that solution. I think we had better leave DST alone if no rules are available. Guessing rules always means to do exactly the wrong thing for half of the world, assuming rules that are suitable for the northern hemisphere means to discriminate the southern hemisphere. Correct me if I'm wrong, but isn't it possible to explicitely mark that question as undecidable by setting tm->tm_isdst resp. the variable daylight to -1? Collecting back data which will most probably provide wrong results looks a little ridiculous to me. What should we do when time_t grows 64 bits big? Guess if Alexander arrived one hour early at Issos because the Greek had DST and the Persians hadn't?
In zic.c, the analysis of the return value of system("yearistype ...") assumes a certain structure of that return value.
That's clearly a portability bug; here's a patch.
Fine.
+#if HAVE_SYS_WAIT_H - 0 +#include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */ +#endif /* HAVE_SYS_WAIT_H - 0 */ + +#ifndef WIFEXITED +#define WIFEXITED(status) (((status) & 0xff) == 0) +#endif /* !defined WIFEXITED */ +#ifndef WEXITSTATUS +#define WEXITSTATUS(status) (((status) >> 8) & 0xff) +#endif /* !defined WEXITSTATUS */
Will that work on BSD systems with a union wait? system() returns int, so what does BSD recommend to get the status bits? Sorry, I don't know, I just want to point out a possible problem. Ciao Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de