1752 – std.date.LocalTimetoUTC applies wrong daylight savings time adjustments in EU timezones

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

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

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

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.

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

Jonathan, if you're around can you confirm that datetime doesn't suffer from this same issue? If so this should be closed.

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.

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

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.

It's unlikely this D1 issue will get worked on, if anyone plans to work on it feel free to reopen.