www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1752] New: std.date.LocalTimetoUTC applies wrong daylight savings time adjustments in EU timezones

reply d-bugmail puremagic.com writes:
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).


--
Dec 28 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752






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);


--
Dec 28 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752


matti.niemenmaa+dbugzilla iki.fi changed:

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





-------
Have a look at Issue 1436. I'm not sure, but I think the way Walter fixed it is
still bogus.


--
Dec 29 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752






Thanks, I didn't see issue 1436 as I was only searching for issues for
'LocalTimetoUTC'.


   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.


--
Dec 29 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752






The following further changes to std\date.d (in addition to the above) appear
to
fix the Windows version of LocalTimetoUTC():


        : t - LocalTZA - DaylightSavingTA(t - LocalTZA);
to:
        : t - LocalTZA - DaylightSavingTA(t);



        time = 0;
to:
        time = MakeTime(st.wHour, st.wMinute, 0, 0);



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


--
Dec 30 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752




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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1752




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: -------
May 25 2011