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: timezone daylight tzname altzone and it does reset them if TZ is not set properly. localtime() calls tzset(), so it will change the tzname[] values. joel