To: dj AT ctron DOT com (DJ Delorie)
Cc: storner AT olicom DOT dk, djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Why TZ=EST5EDT fails 
Date: Sun, 28 Aug 94 10:32:41 +0200
From: eliz AT is DOT elta DOT co DOT il


Through this weekend I've also discovered and fixed all the problems
concerning time routines which DJ described in the 3rd beta of 1.12m1.
These fixes should also enable to resurrect the original and, I think,
correct code inside tzset(), which calls tzsetwall() if TZ is not present
in the environment, thus implementing the documented behavior of using
the ``local wall clock'':

	name = getenv("TZ");
	if (name == NULL) {
#if 0
	    tzsetwall();
	    return;
#else
	    name = "EST5";
#endif

I suspect this #if 0 is for consistency with Turbo C 2.0, and is the
only way to make time routines correct when TZ is not defined without
tossing Turbo C runtimes.  Am I right, DJ?  Anyhow, with gettimeofday
replaced, there is no need for this.

Btw, the docs for gettimeofday() incorrectly say that tv_sec is
seconds since Jan 1st, 1980, not 1970.  A correction is due.

I was able to verify the correct behavior, as documented by ctime(3)
man page, by using zoneinfo files from a Unix workstation.  After
replacing gettimeofday() and re-enabling tzsetwall(), everything worked
as advertised.

So, those of you who want to continue to work in local time, should
leave TZ undefined.  Those who want to be POSIXLY-CORRECT, should
either define a full POSIX TZ string or point TZ to a zoneinfo file.

"Cave Newt" <roe2 AT midway DOT uchicago DOT edu> writes:
> > I guess there isn't much that can be done about this. Distributing
> > zoneinfo files with DJGPP seems a bit much; picking a default rule to
> > apply when none is specified in the TZ setting is bound to fail on
> > some systems - the very reason for the zoneinfo files being that DST
> > changes are not universally coordinated.
>
> I don't understand the second comment.  How do you get from TZ=EST5EDT
> to "none is specified in the TZ setting"?  Picking the default rule to
> be the same as if TZ=EST5 is much better than the current default of
> pretending it's GMT0; and guessing at the dates for DST is better still
> --you're off by an hour for at most a few days per year instead of for 
> six months per year (or, as is currently the case, off by many hours for 
> the whole year :-) ).

I think this is not a question of what's ``much better'' but rather ``what
POSIX says'' (or any other document which DJGPP should conform to).  Once
again, is there anybody who knows where the definition of ctime and friends
can be found, besides Unix man pages?  Or should we just take the behavior
of ctime.c in the library as the de-facto standard?

That about settles the issue of time routines.

Which leaves us with stat().  DJ writes:

> stat() should return all times as GMT times.  This means that, on DOS,
> you have to use the local-time timestamps and convert them (using TZ)
> to GMT times.

This is easy to implement by getting file's time stamp from DOS, then
calling mktime() with that time stamp and with negative tm_isdst, which
tells mktime() to compute DST setting from TZ.  I did exactly that in a
replacement of stat() for DJGPP (which also repairs many other
aspects of the present implementation), and will post it in a short
while.  But that still leaves a problem of which we should be aware.
Unlike Unix, DOS sets file creation time using *local clock*, not
GMT, so copying a file from a remote machine will change the time
fields which stat() returns (unless, of course, both machines work in
GMT0 or local wall clock).  That is why the existing stat() (which
calls stat() of TC runtime library) doesn't care about TZ: in the DOS
world it is unusual to see file's time stamp change when you move it
from one machine to another.  Now this will start to happen when we use
DJGPP-compiled programs.  This is maybe an unfortunate side effect of
fixing stat(), but hardly anything more could be done here.  We can't
be sure files are only created through calls to DJGPP library, and thus
can't ``fix'' DOS in all cases..  I don't know if this presents a problem
(file moved inside archives, maybe?).  If anybody does, let him speak now.

And lastly, a warning.  Those of you who will want to use timezone
files, should first check if they correctly describe the current state
of legislation in your country.  The files are binary, so you can't easily
look at them.  On Unix machines there are text source files, which can be
read by a human.  If you want to fix them, the Unix command zic(8) will
compile the source file.  Anybody out there knows where I could get the
source for zic?

Hope I helped,
		Eli Zaretskii