From: guy@netapp.com (Guy Harris) Date: Wed, 6 Apr 1994 16:44:48 -0700 (PDT)
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.... Yes. Here is the gdb output. Notice that the `mktime' is tz's (at localtime.c:1404), whereas the strftime is Sun's. I include a backtrace (the output of the GDB `where' command) just before the point of failure -- Sun's strftime isn't handling the `%Z' format correctly for some reason. $ gdb -q date (gdb) b main Breakpoint 1 at 0x10edc: file date.c, line 85. (gdb) r Starting program: /net/twinsun/export/dark/u/eggert/src/lib/tz/date Breakpoint 1, main (argc=1, argv=0xeffffc0c) at date.c:85 85 register int aflag = 0; (gdb) b mktime Breakpoint 2 at 0x140d0: file localtime.c, line 1404. (gdb) c Continuing. Breakpoint 2, mktime (tmp=0xeffff9ec) at localtime.c:1404 1404 return time1(tmp, localsub, 0L); (gdb) c Continuing. Breakpoint 2, mktime (tmp=0xeffff9ec) at localtime.c:1404 1404 return time1(tmp, localsub, 0L); (gdb) where #0 mktime (tmp=0xeffff9ec) at localtime.c:1404 #1 0xef77fc14 in strftime () #2 0x1171c in timeout (fp=0x28220, format=0x145b0 "%X %Z %Y", tmp=0xeffffae8) at date.c:526 #3 0x11628 in display (format=0x0) at date.c:491 #4 0x112d0 in main (argc=1, argv=0xeffffc0c) at date.c:288 (gdb) c Continuing. Breakpoint 2, mktime (tmp=0xeffff93c) at localtime.c:1404 1404 return time1(tmp, localsub, 0L); (gdb) c Continuing. Wed Apr 6 19:44:40 1994 Program exited normally. (gdb)
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? That's correct -- the SunOS 5.3 <time.h> uses a minimal `struct tm'. 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. That's true. But since mktime _is_ in the ANSI C name space, Sun doesn't have to (and doesn't) play that game with mktime. There is no `_mktime' in the library, and if you redefine mktime, as the tz package's `date' does, you're on your own. Could the 5.x "strftime()" be calling the 5.x "tzset()" rather than the "tzset()" from the library you've built? No. Here is a GDB session that shows this. tzset is being called only from localtime(). $ gdb -q ./date (gdb) b main Breakpoint 1 at 0x10edc: file date.c, line 85. (gdb) r Starting program: /net/twinsun/export/dark/u/eggert/src/lib/tz/./date Breakpoint 1, main (argc=1, argv=0xeffffc0c) at date.c:85 85 register int aflag = 0; (gdb) b tzset Breakpoint 2 at 0x132fc: file localtime.c, line 868. (gdb) b _tzset Breakpoint 3 at 0xef782dac (gdb) c Continuing. Breakpoint 2, tzset () at localtime.c:868 868 name = getenv("TZ"); (gdb) where #0 tzset () at localtime.c:868 #1 0x133e8 in localsub (timep=0xeffffae4, offset=0, tmp=0x24bb8) at localtime.c:920 #2 0x1350c in localtime (timep=0x24800) at localtime.c:962 #3 0x11598 in display (format=0x0) at date.c:487 #4 0x112d0 in main (argc=1, argv=0xeffffc0c) at date.c:288 (gdb) c Continuing. Wed Apr 6 22:11:44 1994 Program exited normally.