Date: Mon, 15 Aug 94 00:11:34 CDT From: "Cave Newt" To: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: broken djgpp 1.12 timezone functions I've only just joined the djgpp list, so I have no idea to whom this should be addressed. However... I've just been investigating djgpp's handling of timezone information, and basically (forgive my bluntness) it's just plain wrong. I've looked through the djgpp docs I have, looking for any references to special procedures or whatever, and I can't find any. So I assume the problem is simply not yet known. There are several paths to the timezone information, and it appears that all of them are broken. Probably the most commonly used is the st_mtime value in struct stat; this must convert between MS-DOS (local) time and GMT-based Unix time. Without changing my system clock to test non-DST, it appears that stat() simply assumes every- body lies four hours west of GMT. The use of the TZ variable and the tzset() (initialization) function had absolutely no effect on the time returned by stat(). Bug #1. The second path, and the one chosen by whoever did the djgpp port of UnZip, is to use the Berkeley ftime() function. This, at least, is vaguely in the ballpark; the following table summarizes my findings: djgpp 1.12 using ftime(): with no TZ variable: timezone adds 5 hours; DST adds zero ok... with TZ=PST8: timezone adds 8 hours; DST adds zero good with TZ=PST8PDT: timezone adds zero; DST adds zero WRONG "existing" is same in all 3 cases (== "GMT" + 4 hours) WRONG What this means is that: (1) without the TZ environment variable set, ftime() assumes either the US/Eastern or US/Central timezone (there is no support for Daylight Savings Time in any of this); this is acceptable behavior, although my personal preference is for GMT to be the default (i.e., as if TZ=GMT0). (2) With TZ=PST8PDT (the correct setting for my location), ftime() acts as though I set it to GMT0--there is no timezone adjustment at all (bug #2). (3) With TZ=PST8 (not quite correct, but I could live with it), ftime() adds 8 hours--this is completely correct. However, because of the stat() bug (bug #1, and what the "existing" ref- erence in the last line of the summary means), UnZip still doesn't work right. At this point I looked up timezone functions and found the reference to the SysVish tzset(), which is becoming the standard and is normally what we use by default. Unfortunately, the accompanying extern variable "timezone" is not even initialized by tzset, as near as I can tell: djgpp 1.12 using tzset()/timezone: timezone completely bogus in all cases (768238718 -> -2052067885: ??) WRONG This would be bug #3. Finally, just for kicks, I tried adding a call to tzset() ("initialize timezone info) before the regular ftime() stuff; it had no effect on the ftime() results noted above. For reference, here are the results for two other DOS compilers: emx 0.8h.10: with no TZ variable: timezone adds zero; DST adds zero good with TZ=PST8: timezone adds 8 hours; DST adds zero good with TZ=PST8PDT: timezone adds 8 hours; DST adds zero ok... "existing" matches timezone/DST-adjusted "archive" time in each case good MSC 7.0 with 6.0 libraries: with no TZ variable: timezone adds 8 hours; DST subtracts one ok... with TZ=PST8: timezone adds 8 hours; DST adds zero good with TZ=PST8PDT: timezone adds 8 hours; DST subtracts one good "existing" matches timezone/DST-adjusted "archive" time in each case good emx is the gcc-based programming environment by Eberhard Mattes; it's primarily used in the OS/2 world, but it does have a DOS counterpart and allows the same 32-bit executable to run under either DOS or OS/2. Its primary disadvantage relative to djgpp is its use of a VCPI-based extender; while there is a third-party DPMI-based one available (RSX, which also works with djgpp executables), it's more kludgy to use than is go32. MSC, of course, is Microsoft's compiler. Anyway, emx+gcc behaves quite nicely except that it ignores DST, and MSC is essentially perfect in its behavior (much as it pains me to praise Microsoft). Its only (minor) drawback is that it, too, assumes a non-GMT timezone in the absence of the TZ variable (US/Pacific). I tested it with TZ=CST6CDT, btw, and it works; the Pacific timezone isn't hardwired. Note that stat() in both MSC and emx matches the timezone information returned by tzset()/timezone. OK, enough rambling. I have no particular interest in MS-DOS compilers except insofar as they affect the operation of UnZip, so no, I'm not volunteering to go fix this myself. :-) I would appreciate it if someone else would do so, however, since the only work-around appears to be for the whole world to set TZ=FOO4 in order to use unzip386's freshen and update options. Big thanks in advance to anyone who can do so. I have a whole other bug report on make 3.71 and its broken recursive quoting, but that will have to wait for another day... Regards, Greg Roelofs Info-ZIP