Thread overview
[Issue 1752] New: std.date.LocalTimetoUTC applies wrong daylight savings time adjustments in EU timezones
Dec 28, 2007
d-bugmail
Dec 29, 2007
d-bugmail
Dec 29, 2007
d-bugmail
Dec 29, 2007
d-bugmail
Dec 30, 2007
d-bugmail
May 25, 2011
Andrej Mitrovic
May 25, 2011
Jonathan M Davis
May 25, 2011
Andrej Mitrovic
May 25, 2011
Jonathan M Davis
December 28, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1752

           Summary: std.date.LocalTimetoUTC applies wrong daylight savings
                    time adjustments in EU timezones
           Product: D
           Version: 1.024
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: grahamc001uk@yahoo.co.uk


Uncommenting the 'printf()' in std\date.d line line 744 gives output like (for
years 2003 2004):

month = 10, wDayOfWeek = 0, wDay = 5, mday = 33
month = 3, wDayOfWeek = 0, wDay = 5, mday = 30

month = 10, wDayOfWeek = 0, wDay = 5, mday = 31
month = 3, wDayOfWeek = 0, wDay = 5, mday = 35

mday goes beyond the last day of October 2003 and March 2004 (an likewise in future years) causing daylight savings time adjustments to be applied on the wrong dates.

I am in the GMT time zone. The problem is probably present in all EU timezones where the daylight savings change takes place on the last Sunday in March and October (so windows function GetTimeZoneInformation() returns a 5 in the week of the month fields where the change is applied).


-- 

December 29, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1752





------- Comment #1 from grahamc001uk@yahoo.co.uk  2007-12-28 20:16 -------
This simple patch is good enough to fix the date of daylight savings adjustment in all EU timezones. It is not general enough to cope with any customized timezone (those with an adjustment in the last week of Feb or Jun or Sep).

There still appears to be a problem with the time of day when some daylight savings adjustments are made in EU timezones - some occurring at 11pm UTC instead of 1am UTC. This does not fix that.

            mday += (st.wDay - 1) * 7 + 1;

            // Start of patch. Insert into file std\date.d at line 744
            if (mday>30 && (mday>31 || month==3 || month==10))
                mday -= 7;
            // End of patch.

            //printf("month = %d, wDayOfWeek = %d, wDay = %d, mday = %d\n",
st.wMonth, st.wDayOfWeek, st.wDay, mday);


-- 

December 29, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1752


matti.niemenmaa+dbugzilla@iki.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code




------- Comment #2 from matti.niemenmaa+dbugzilla@iki.fi  2007-12-29 10:35 -------
Have a look at Issue 1436. I'm not sure, but I think the way Walter fixed it is still bogus.


-- 

December 29, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1752





------- Comment #3 from grahamc001uk@yahoo.co.uk  2007-12-29 12:02 -------
Thanks, I didn't see issue 1436 as I was only searching for issues for 'LocalTimetoUTC'.

I think line #747:
   time = 0;

in std\date.d is wrong as this seems to make all daylight savings adjustments occur at midnight local time instead of the actual time (2am or 1am etc.) retrieved from the registry. This explains the 11pm UTC adjustment when in the UK timezone. I would think that this would also make all the U.S. daylight savings adjustments occur at the wrong times (at midnight instead of at 2am local time as they should).

I think the code is best examined by the original author as I find it rather difficult to follow.


-- 

December 30, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1752





------- Comment #4 from grahamc001uk@yahoo.co.uk  2007-12-30 16:28 -------
The following further changes to std\date.d (in addition to the above) appear
to
fix the Windows version of LocalTimetoUTC():

Change line #410 from:
        : t - LocalTZA - DaylightSavingTA(t - LocalTZA);
to:
        : t - LocalTZA - DaylightSavingTA(t);


Change line #747 from:
        time = 0;
to:
        time = MakeTime(st.wHour, st.wMinute, 0, 0);


Change line #814 from:
        if (td <= dt && dt <= ts)
to:
        if (td <= dt && dt < ts)



I've only looked at the Windows code. The Linux code appears to be hard coded
for the old U.S. daylight savings adjustments - so that has been incorrect
since
March 11 2007 for the U.S. and has never worked for any EU or for most of the
rest of the world timezones.

The are almost certainly some problems with UTCtoLocalTime() as well (both
Windows and Linux). I've only been checking LocalTimetoUTC().


-- 

May 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1752


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #5 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-24 23:17:20 PDT ---
Jonathan, if you're around can you confirm that datetime doesn't suffer from this same issue? If so this should be closed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1752


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-24 23:43:19 PDT ---
The std.date bugs are std.date-specific and have _nothing_ to do with std.datetime. Any and all std.date bugs are irrelvent to std.datetime and bugs for std.datetime should be submitted separately.

However, while std.date is going away in D2, it's still around for D1, so std.date bugs still apply to D1, and they can't necessarily be closed (though I question that they'll ever be fixed). Notice that this bug is marked as D1-only.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1752



--- Comment #7 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-25 00:08:46 PDT ---
Hmm yeah it's D1. I might have closed a D1 bug without noticing, argh. Sorry about that, I'll check other reports if I've closed any by accident.

However, I really doubt Walter is going to work on fixing this. Whoever is still using D1 is likely using Tango anyway. And this is a 4 year old bug, if it's still not closed, well.. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1752



--- Comment #8 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-25 00:13:56 PDT ---
Yes, it's highly unlikely that it's going to be fixed, but it's still a valid bug. If Walter wants to close it as Won't Fix, then he can. I pretty much just ignore all of the D1 bugs, since I don't use D1 at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------