I think I've figured out the problem with tz-1994e under Solaris 2.3. Guy Harris's intuition was right -- it was the leading-`_' symbols. The problem is that tz-1994e's `date' command calls Sun's strftime, which invokes mktime to set _tzname (not tzname, since a non-Posix Standard C program might have its own external variable called tzname, so the Sun tzname is a weak reference to _tzname). But the tz package defines its own mktime, which sets tzname (which is qnot _tzname). Sun's mktime never gets invoked and therefore Sun's _tzname never gets initialized. I think that this bug will happen in any SVR4 system, regardless of whether -DUSG_COMPAT and -DTM_GMTOFF. The only fix that I can see for tz is the one I already submitted, namely to use tz's strftime instead of the one supplied with the system, as follows: =================================================================== RCS file: Makefile,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c -r1994.5.1.1 -r1994.5.1.2 *** Makefile 1994/04/03 02:54:41 1994.5.1.1 --- Makefile 1994/04/03 19:47:59 1994.5.1.2 *************** *** 280,292 **** if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's logwtmp and strftime in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a logwtmp.o strftime.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o $@ rm -f ,lib.a --- 280,292 ---- if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's getopt and logwtmp in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a getopt.o logwtmp.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \ -lc ,lib.a -o $@ rm -f ,lib.a