A point of curiosity: Sun's strftime invokes mktime, which is tz's mktime in this case.
Are you certain that it's not calling the 5.x "mktime()"? See below....
Perhaps Sun's strftime expects something out of mktime that tz's mktime does not provide. I wonder why it calls mktime at all?
5.x doesn't have "tm_zone" nor "tm_gmtoff" in "struct tm", does it? The SVR4 ABIs don't include it, and I don't think the SVR4 code from AT&T did. Hmm. I just remembered - C library code in SVR4-derived systems like 5.x, when calling routines not in, I think, the ANSI C name space, prepend an underscore to the name of the routine. Routines in the C library with names not in the ANSI C name space have that underscore prepended; references to the name without the prepended underscore resolve to the routine from the library if there's no routine in the program itself with the no-prependend-underscore name, or something such as that. Now, I'm not sure what happens to calls to the prepended-underscore name if there is a routine in the program with the no-prepended-underscore name, but I suspect it does *not* resolve to the routine in the program; that way, if you have a routine named "read()" in your program (where "in your program" includes "in a library of your own linked into your program), you don't break any ANSI C routines (e.g., standard I/O library routines) that might call "_read()" to do file system I/O. Could the 5.x "strftime()" be calling the 5.x "tzset()" rather than the "tzset()" from the library you've built? If so, is there some reason to expect the 5.x "tzset()" routine to e.g. fail to find the time zone file?