From: guy@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.