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

Joel Tornatore Joel.Tornatore at Eng.Sun.COM
Mon Apr 4 16:39:09 UTC 1994

> > 1.  The Solaris 2.3 strftime gets confused about the timezone when
> > it's linked together with `date'.  I don't have the Solaris 2.3
> > source, so I don't know the details, but my guess is that Solaris 2.3
> > strftime assumes that tzset sets some global variables in the Solaris
> > 2.3 library, but since we've substituted our own tzset this assumption
> > no longer applies.  The symptoms are that `date' prints the correct
> > time but with either "GMT" or "" substituted for the time zone name.
> As I remember, in SV-derived systems, "tzset()" will set the "timezone",
> "daylight", and "tzname" variables; in systems derived from more recent
> SV's (SVR3.1 and later, I think), it also sets "altzone".
> SunOS 5.3 is SVR4-derived, so any time zone code installed on it should
> arrange to set "timezone", "altzone", "daylight", and "tzname" when
> "tzset()" is called.  (It may, I think, reset them if there aren't
> single values for them that make sense - e.g., if there are different
> time zone abbreviations for standard time at different dates, or
> different time zone abbreviations for summer time at different dates, I
> think "localtime()" may change the setting of "tzname".  That, at least,
> was the intent.)
> It may be that "strftime()" is expecting "tzname" to be set; if it's not
> being set, that may be the source of the problem.

The SunOS 5.3 version of tzset() does set these variables:

and it does reset them if TZ is not set properly.

localtime() calls tzset(), so it will change the tzname[] values.


More information about the tz mailing list