FW: POSIX-TZ without rules

Guido Flohr gufl0000 at stud.uni-sb.de
Sun May 2 23:28:21 UTC 1999

On Thu, Apr 29, 1999 at 04:39:29PM -0700, Paul Eggert wrote:
>    From:	Guido Flohr [SMTP:gufl0000 at 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

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.


> +#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.


mailto:gufl0000 at stud.uni-sb.de

More information about the tz mailing list