From: Eric Backus <ericb AT lsid DOT hp DOT com>
Subject: Re: Bug in time
To: Paul DOT Loewenstein AT Eng DOT Sun DOT COM (Paul Loewenstein) (Paul Loewenstein)
Date: Wed, 16 Sep 92 11:21:32 PDT
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Mailer: Elm [revision: 66.25]

> There appears to be a bug in version 1.08 time.  It gives a result
> which is one hour slow.  When the system date is set to winter
> (I forget which date I used), the problem went away.
> 
> DJGPP:
> 
> C:\TEMP>go32 test
> 
> c:/gcc/bin/go32.exe version 1.08 Copyright (C) 1991 DJ Delorie
> Mon Sep 14 20:19:36 1992
> 
> TURBO C:
> 
> C:\TEMP>test
> 
> Mon Sep 14 21:20:05 1992

I ran into this as well.  It appears to be an inconsistancy between
the treatment of timezones in DJGPP's libsrc/c/lib/ctime.c versus the
treatment of timezones in Turbo C.

I believe the problem is that if no timezone is specified, DJGPP
assumes that there is no daylight savings time, while Turbo C assumes
that daylight savings time follows the US convention.  This makes the
times different by one hour during daylight savings time.

I've worked around this problem on my machine by specifying the
timezone in the environment variable "TZ".  However, finding the
correct value for TZ was, well, not easy.  On a real unix machine, you
set TZ to something like "PST8PDT", and the time functions look up PST
in /usr/lib/tztab and figure out whether daylight savings time is in
use.  With DJGPP, we don't have /usr/lib/tztab.  This means that TZ
needs to specify the time zone (PST or PDT for me), and ALSO specify
when daylight time starts and ends during the year.  I ended up with
the following cryptic string, which I placed in my autoexec.bat, by
reading my way through libsrc/c/lib/ctime.c:

	TZ="PST8PDT,M4.1.0,M10.4.0"

This string says that my timezone is PST which is 8 hours away from
GMT, that the timezone is called PDT when daylight savings time is in
effect, that daylight savings time starts on the sunday of the first
week of April, and ends on the sunday of the fourth week of October.
With this string set in the environment, the time function appears to
work consistantly.
--
				Eric Backus
				ericb%hplsla AT hplabs DOT hp DOT com
				(206) 335-2495