linking problems with tz-1994e `date' on Solaris 2.3
Paul Eggert
eggert at twinsun.com
Tue Apr 5 22:46:18 UTC 1994
From: guy at netapp.com (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