To: "Cave Newt" Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: Why TZ=EST5EDT fails Date: Tue, 30 Aug 94 08:18:21 +0200 From: eliz AT is DOT elta DOT co DOT il > And all machines I've > tested (Sun, SGI, Convex, Cray) honor the 7-character TZ setting properly, > even with garbage for the timezone names (e.g., my wife's and my initials). > So they can't be too dependent on the zoneinfo files. Peeking deeper into the tzset() code (file ctime.c in the library source) reveals this: tzset() gets TZ from the environment, say it is EST5EDT. First, it calls tzload() which tries to open and read file by that name in a directory which holds zoneinfo files (because EST5EDT doesn't start with a slash). Failing that, it looks at the first character of TZ. If it's a colon, then it *must* be a file, and tzset() defaults to GMT0. In this case, there is no colon, so tzset() summons tzparse() which tries to get all the required info from the TZ string. If TZ contains only EST5, then tzparse decides the offset from GMT is 5 hours and no DST is in effect, and exits successfully. In this case, however, there is more after EST5, so tzparse() understands that DST *might* be in effect. It then either takes the DST offset from TZ, if it's there, or (in this case) assumes it's one hour less than standard offset. If TZ doesn't contain a full Posix specification of when DST starts and ends, tzparse() *requires* that a file called ``posixrules'' be present in the same directory where other zoneinfo files reside. If found, it is used to deduce whatever info is missing from TZ. Failing that, tzparse() fails and tzset() then defaults to GMT0. (Most of the above was already posted by Henrik Storner several days ago, but I thought I just put it here for completeness.) So it appears to me, that for a Unix machine to go GMT0 when TZ is present but incomplete, the file ``posixrules'' has also to be moved/deleted, at least for BSD machines (assuming our ctime.c is what is actually used on BSD machines also). Eli Zaretskii