Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
X-Authentication-Warning:	inwis01.heidelberg.com: adm set sender to <Stefan DOT Weil AT de DOT heidelberg DOT com> using -f
Message-ID:	<7B9327EED0AAD211B0750090270F68EC2A16E9@hdhexmbx02.ger02.heidelberg.com>
From:	"Weil, Stefan 7732 EPE-24" <Stefan DOT Weil AT de DOT heidelberg DOT com>
To:	"'cygwin AT sourceware DOT cygnus DOT com'" <cygwin AT sourceware DOT cygnus DOT com>
Subject:	Daylight saving bug in winsup/times.cc
Date:	Tue, 23 Mar 1999 09:10:26 +0100
MIME-Version:	1.0
X-Mailer:	Internet Mail Service (5.5.2232.9)
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id DAA02874

Hello,

DJ wrote in his mail from Thu, 11 Mar,

>> For some days, i've been experiencing a strange time leap in the date
batch or
>> in my asclock. The hour given is 1 hour ahead the real date. The date in
the

>Do you have "automatic adjustments" enabled in your date/time settings?

>We've found a bug in NT that it reports timezone info wrong if this is
>set, right around the times when you'd change from standard to
>daylight time, and disabling the automatic adjustments seems to fix
>it.

We also got a time shift of one hour ahead the real time. We have automatic
adjustments enabled. But I do not think that this is caused by an NT bug:
It is a feature of NT's GetTimeZoneInformation API.

Here are our NT registry settings:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\TimeZoneInformation]
"Bias"=dword:ffffffc4
"StandardName"="Westeuropäische Normalzeit"
"StandardBias"=dword:00000000
"StandardStart"=hex:00,00,0a,00,05,00,03,00,00,00,00,00,00,00,00,00
"DaylightName"="Westeuropäische Sommerzeit"
"DaylightBias"=dword:ffffffc4
"DaylightStart"=hex:00,00,03,00,05,00,02,00,00,00,00,00,00,00,00,00
"ActiveTimeBias"=dword:ffffffc4

Exactly the same values are returned with GetTimeZoneInformation.
Here is the gdb output in function localtime, after GetTimeZoneInformation:

(gdb) p tz
$9 = {Bias = -60, StandardName = {87, 101, 115, 116, 101, 117, 114, 111,
112,
    228, 105, 115, 99, 104, 101, 32, 78, 111, 114, 109, 97, 108, 122, 101,
    105, 116, 0, 0, 0, 0, 0, 0}, StandardDate = {wYear = 0, wMonth = 10,
    wDayOfWeek = 0, wDay = 5, wHour = 3, wMinute = 0, wSecond = 0,
    wMilliseconds = 0}, StandardBias = 0, DaylightName = {87, 101, 115, 116,
    101, 117, 114, 111, 112, 228, 105, 115, 99, 104, 101, 32, 83, 111, 109,
    109, 101, 114, 122, 101, 105, 116, 0, 0, 0, 0, 0, 0}, DaylightDate = {
    wYear = 0, wMonth = 3, wDayOfWeek = 0, wDay = 5, wHour = 2, wMinute = 0,
    wSecond = 0, wMilliseconds = 0}, DaylightBias = -60}

According to the Microsoft documentation (see online help from Dev Studio),
wYear == 0 needs a different algorithm. This algorithm is not implemented in

function localtime, file winsup/times.cc, so localtime fails.

Our registry entry simply says that daylight saving time starts at the
last (wDay = 5) sunday (wDayOfWeek = 0) in march (wMonth = 3) 
every year (wYear = 0) at 2 AM (wHour = 2, wMinute = 0).
This is correct - it starts next sunday! CYGWIN thinks it already has
started
and incorrectly adds 60 minutes.

Perhaps somebody already has some code which fixes function localtime?

Here is the pseudo code which should fix localtime:

	if (StandardDate.wYear != 0) {
		Get dst stop time with algorithm from current
implementation.
	} else {
		if (StandardDate.wDay >= 1 && StandardDate.wDay <= 4) {
			dst stop is at the 1st, 2nd, 3rd or 4th wDayOfWeek
			in month StandardDate.wMonth.
		} else if {StandardDate.wDay == 5) {
			dst stop is at the last wDayOfWeek.
		}
	}

	Get dst start time from DaylightDate (same algorithms).

Thank you,

Stefan Weil (stefan DOT weil AT de DOT heidelberg DOT com).


-----Original Message-----
From: Geoffrey Noer [mailto:noer AT cygnus DOT com]
Sent: Tuesday, March 23, 1999 5:56 AM
To: Weil, Stefan 7732 EPE-24
Subject: Re: Daylight saving bug in winsup/times.cc


Hi,

I think DJ wrote mail to the Cygwin list recently about the Win32 API
bug that causes this problem.  Search the archives for "timezone" and
you will probably find it.  If you still think there's a Cygwin bug,
please send the details to the developer's mailing list
(cygwin-developers AT sourceware DOT cygnus DOT com).

Thanks,
gjn


On Mon, Mar 22, 1999, Weil, Stefan 7732 EPE-24 wrote:

> Hello Geoffrey,
> 
> we experienced a small bug in function localtime (times.cc) since a couple
> of days.
> With this bug, "date" shows a wrong time and "configure" says that the
build
> environment
> is broken.
> 
> You wrote something about a possible bug in your mail dated 10/12/98 where
> you
> announced a new winsup snapshot.
> 
> Maybe here is the reason what wents wrong:
> Function localtime calls GetTimeZoneInformation from the Win32 API. This
> function
> gives start time and end time of the daylight saving period. It supports
two
> different representations:
> 
> 1. Absolute times. This is supported by CYGWIN.
> 
> 2. Relative times ("daylight saving starts last sunday in march at 0:00").
>     This is not supported by CYGWIN. So all european installations show a
> wrong date.
> 
> GetTimeZoneInformation sets StandardTime.wYear = 0 for the second
> representation.
> CYGWIN does not check this and always assumes the first representation.
> 
> I am sorry that I cannot supply some code which fixes this bug. But as you
> mentioned in your
> mail: Next week, it will be fixed automatically, because then we have
> daylight saving time:-)
> 
> Sincerely,
> 
> Stefan
> 
> Stefan Weil

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -