Daylight saving bug in winsup/times.cc

Daylight saving bug in winsup/times.cc

[Weil, Stefan 7732 EPE-24]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]

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.weil@de.heidelberg.com).


-----Original Message-----
From: Geoffrey Noer [ mailto:noer@cygnus.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@sourceware.cygnus.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@sourceware.cygnus.com

Re: Daylight saving bug in winsup/times.cc

[DJ Delorie]

> (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.

Cygwin uses the Bias field.  In your example, it's set to -60, which
means that daylight savings time has already started.  The MSDN docs
desribe this field as "Specifies the current bias, in minutes, for
local time translation on this computer."  So, the information in the
Bias field, for your computer, is currently wrong.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Daylight saving bug in winsup/times.cc

[Weil, Stefan 7732 EPE-24]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4954 bytes --]

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.weil@de.heidelberg.com).


-----Original Message-----
From: Geoffrey Noer [ mailto:noer@cygnus.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@sourceware.cygnus.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@sourceware.cygnus.com

Re: Daylight saving bug in winsup/times.cc

[DJ Delorie]

> (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.

Cygwin uses the Bias field.  In your example, it's set to -60, which
means that daylight savings time has already started.  The MSDN docs
desribe this field as "Specifies the current bias, in minutes, for
local time translation on this computer."  So, the information in the
Bias field, for your computer, is currently wrong.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Daylight saving bug in winsup/times.cc

[Jörg Schaible]

Lapo Luchini wrote on Thursday, October 16, 2003 11:07 AM:
> Anyway I guess that a correct "timezone" variable can solve
> your issue. (but usually it is "ok" also without anything defnied)

A little Google search pops up Corinna's famous settings in the first position:
http://www.google.de/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=site%3Acygwin%2Ecom+Corinna+TZ


Regards,
Jörg

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Daylight saving bug in winsup/times.cc

[Lapo Luchini]

no reply outside of the mailing list, please.

>The problem is that cygwin has switch to winter-time since 05/10/2003.
>The winter-time will begin end october.  
>  
>
An early switch?
This is very unexpected...

>Now I have already found a new date.exe who gives me the right time.
>  
>
"new date.exe"? Please specify...
What are differences, where did you find it, and so on.

Anyway I guess that a correct "timezone" variable can solve your issue.
(but usually it is "ok" also without anything defnied)

$ man tzset

Lapo

-- 
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Daylight saving bug in winsup/times.cc

[Lapo Luchini]

Vanlerberghe Ignace wrote:

>>Since the 5 th october there is a difference of one hour between the correct NT-server time and the wrong cygwin time.
>>    
>>
Was the server rebooted since daylight saving time or it is still active?
Have you tried to let the cygwin DLL unload (e.g. closing all CygWin 
software for a minute or so?).

-- 
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Daylight saving bug in winsup/times.cc

[Vanlerberghe Ignace]

> Hello,
> 
> We are using an old versio of cygwin :   uname -a = CYGWIN32_NT NTDATAKOR 5.0 17.6 i686
> 
> Now we are dealing with a daylight saving problem because the time from the NT-server must be correct for our application.
> 
> Since the 5 th october there is a difference of one hour between the correct NT-server time and the wrong cygwin time.
> 
> Since you have been envolved with this problem (found in mail archives) may I ask you if there is a solution to it ?
> 
> Kind Regards
> 
> Ignace Vanlerberghe
> 
> Datakor Software Team
> President Kennedypark 30
> 8500 Kortrijk
> Belgium
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Daylight saving bug in winsup/times.cc

[Jörg Schaible]

Vanlerberghe Ignace wrote on Wednesday, October 15, 2003 3:10 PM:
>> We are using an old versio of cygwin :   uname -a =
> CYGWIN32_NT NTDATAKOR 5.0 17.6 i686
>> 
>> Now we are dealing with a daylight saving problem because the time
>> from the NT-server must be correct for our application.
>> 
>> Since the 5 th october there is a difference of one hour between the
>> correct NT-server time and the wrong cygwin time.
>> 
>> Since you have been envolved with this problem (found in mail
>> archives) may I ask you if there is a solution to it ?

Upgrade!

Regards,
Jörg

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Daylight saving bug in winsup/times.cc

[Vanlerberghe Ignace]

> Hello,
> 
> We are using an old versio of cygwin :   uname -a = CYGWIN32_NT NTDATAKOR 5.0 17.6 i686
> 
> Now we are dealing with a daylight saving problem because the time from the NT-server must be correct for our application.
> 
> Since the 5 th october there is a difference of one hour between the correct NT-server time and the wrong cygwin time.
> 
> Since you have been envolved with this problem (found in mail archives) may I ask you if there is a solution to it ?
> 
> Kind Regards
> 
> Ignace Vanlerberghe
> 
> Datakor Software Team
> President Kennedypark 30
> 8500 Kortrijk
> Belgium
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/