TortoiseSVN The coolest Interface to (Sub)Version Control

During the last few weeks, I got a lot of crash reports for TortoiseSVN which indicated that a certain date API returned bogus data, which either lead to a crash (hence the crash reports) or garbled date strings in various TortoiseSVN dialogs (these were reported on our mailing lists).

From the crash dump files, I could see where the crash happened, why the crash happened there. But what remained unclear was why the date API returned illegal data.

I've tried to reproduce the problem with a small test application that feed random dates to that API, even illegal dates (e.g., Feb, 30). But the API always returned valid data or returned with an error code and left the output data intact. So there had to be some other reasons for this issue.

So I tried contacting those who sent me those crash reports with the dump files. The first few either didn't respond or the reply address was not valid. Then finally a few days ago Asaf Salhov answered my questions and we could figure out the reason behind those problems:

Due to changes in the daylight saving times in Israel, many IT departments tweaked a registry key to make Windows deal with those changes. This worked ok for a long time.
But when Microsoft released service pack 3 for Windows XP, those registry tweaks caused the problem. I still don't know why exactly the installation of the SP3 will cause these problems, but at least we found a solution to fix it:

Either uncheck the "Automatically set Daylight Savings Time" option in your date settings, or try this update from Microsoft: http://support.microsoft.com/kb/953917"

That's all you have to do to fix this problem.

Note: Since I've searched the web for solutions to this problem, I found a lot of other reports for other applications which suffer from the very same problem. That means this is not really an issue with TortoiseSVN or Subversion. So even if you don't use TortoiseSVN but you know (or suspect) that your computer has the above mentioned registry tweak done, you should use tzedit.exe to fix this.

I've written a small tool which should be able to test for this problem. You can download the tool from http://tortoisesvn.net/files/DateTest.exe.
Run the tool in a command line window. The tool tries to convert a fixed system time to a local time (using the SystemTimeToTzSpecificLocalTime API). The tool will show you either an error if the function fails, or the converted date.

If the function call fails, you will see the following output:
SystemTimeToTzSpecificLocalTime failed! GetLastError() returned: 87
The parameter is incorrect.

if the function suceeds, the output is:
SystemTimeToTzSpecificLocalTime succeeded
the resulting SYSTEMTIME is:
Year = 2008
Month = 5
Day of week = 3
Day = 7
Hour = 6
Minute = 7
Second = 59
Milliseconds = 190