Re: Daylight saving bug in winsup/times.cc

[DJ Delorie <dj@delorie.com>]

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