linking problems with tz-1994e `date' on Solaris 2.3

Paul Eggert eggert at
Tue Apr 5 22:46:18 UTC 1994

   From: guy at (Guy Harris)
   Date: Mon, 4 Apr 1994 11:45:33 -0700 (PDT)

   If USG_COMPAT is defined, it appears that it does, indeed, set
   "daylight" and "timezone"; if ALTZONE is defined, it sets "altzone".  It
   appears that it always sets "tzname".

I had not defined USG_COMPAT or ALTZONE, but the problem does not go away
when I do define it.

   Given that, it's not obvious why [the problem] would happen, as
   both versions of "tzset()" should, it appears, set "tzname[]".

I don't know why it happens either.  When Sun's strftime is entered,
the variables in question already have the right values (timezone is
28800, daylight is 1, tzname is {"PST", "PDT"}, and altzone is 25200)
if you compile with USG_COMPAT and ALTZONE.  However, Sun's strftime
does the wrong thing for the %Z format for some reason.

A point of curiosity: Sun's strftime invokes mktime, which is tz's
mktime in this case.  Perhaps Sun's strftime expects something out of
mktime that tz's mktime does not provide.  I wonder why it calls
mktime at all?

So far the best workaround is to avoid linking with the vendor's strftime.

More information about the tz mailing list