www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1993/05/10/14:57:45

From: Eric Backus <ericb AT lsid DOT hp DOT com>
Subject: Re: timezone problem - help required!
To: grimmer AT nyx DOT cs DOT du DOT edu
Date: Mon, 10 May 93 11:20:58 PDT
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (djgpp)
Mailer: Elm [revision: 66.25]

Geoff Rimmer calling from England says:
> The current time is Mon May 10 00:47:14 1993, according to the output
> from the MSDOS 'time' command.
> 
> The output of the above program compiled with DJGPP (2.2.2, 1.08) is
> as follows: 
> 
>     TZ="GMT0BST"
>     time() = 736991234
>     localtime() = Sun May 9 23:47:14 1993
>     gmtime() = Sun May 9 23:47:14 1993
> 
> In the UK we are currently on British Summer Time (BST) which is one
> hour ahead of Greenwich Mean Time (GMT).  So, shouldn't localtime()
> return a time one hour later than gmtime()?  That is, shouldn't
> localtime() show 'Mon May 10 00:47:14 1993'?

Yes, it should.

The source code to the localtime() function needs to know when British
Summer Time starts, in order to know the correct local time.  On unix
machines, this information is normally kept in a file somewhere.  With
DJGPP, you have to specify it in the TZ environment variable.  POSIX
defines a syntax for doing this, which looks something like:
"GMT0BST,M4.1.0,M10.5.0".  The first part of that timezone
specification is your normal "GMT0BST".  The second part specifies
that summer time starts in the first week of the fourth month of the
year, on the zeroth day (Sunday).  The third part specifies that
summer time ends in the fifth week of the tenth month of the year, on
the zeroth day.

I believe that if you set the TZ environment variable like this, your
problem with localtime() will disappear.

However, even if you do this, there is an additional problem: calls
which affect the timestamp on a file don't use the TZ variable, since
they go through Turbo C rather than the DJGPP unix-like libraries.
Instead, I think they just assume that daylight savings time starts
and ends at some fixed date.  This means that there is probably some
window during which the DOS calls won't match your TZ variable, and
file timestamps made during that time will be off by an hour.  I
think.
--
				Eric Backus
				ericb AT lsid DOT hp DOT com
				(206) 335-2495

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019