Date:	Mon, 15 Aug 94 00:11:34 CDT
From:	"Cave Newt" <roe2 AT midway DOT uchicago DOT edu>
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

- Raw text -