TZ/rmail problems again

[Matthias Urlichs]

In comp.unix.aux, article <1991Apr17.054945.21653 at panix.uucp>,
  alexis at panix.uucp (Alexis Rosen) writes:
< urlichs at smurf.sub.org (Matthias Urlichs) writes:  [quoting me about uuxqt]
< >< >The cause of this is a *uuxqt* without TZ set properly.
< >
< >I would like to know why anybody would even _need_ TZ defined as anything.
< >The C library takes care of the whole mess automatically by looking at the
< >appropriate files in /etc/zoneinfo!
< 
< Well, in fact uuxqt and uucico et al. are _not_ broken. It seems that, in
< fact, the C library is broken. Apple knew about this and declined to fix it
< in 2.0.1, but I hear that it definitely will be fixed next time around.
< (This is all from discussions with Apple people who looked into the problem.)
< 
Why, then, does this test program work as expected:

#define _POSIX_SOURCE
#include <sys/types.h>
#include <time.h>
#include <stdio.h>

main() {
   struct tm *t;
   time_t tim; time(&tim);
   t = localtime(&tim);
   t->tm_year += 1900;

   printf("%02d.%02d.%04d %s\n",
	t->tm_mday, t->tm_mon+1, t->tm_year,
	tzname[t->tm_isdst]);
}

??? (TZ is unset. If it's empty, I get GMT which also works as expected.)


< >NB: If I could distribute the binaries I compiled from BSD UUCP, the problem
< >    would go away, but it seems that the legal matters involved prevent me
< >    from doing that. Sorry.
< 
< HDB, you can't distribute. But BSD UUCP binaries should be fine. All A/UX
< users have binary licenses from AT&T so what's the problem? Surely there's
< no difficulty in releasing the stuff that's BSD...
< 
Well, the above impression (in a nutshell) was what I got when asking one of
the local people. If asking the local who's responsible for our licensing
stuff gets me a better answer, I'll ask him instead, no problem.  ;-)

-- 
Matthias Urlichs -- urlichs at smurf.sub.org -- urlichs at smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330)   \o)/