Doing the following on XP and Windows 7 yields different results in a .NET4 vs. a .NET2 console application:
Console.WriteLine(String.Format("DateTime.Parse on Client: {0}",
DateTime.Parse("1998-10-31T00:00:00-04:00")));
.NET4
Under XP this returns: 10/31/1998 12:00:00 AM
Under Windows 7/Windows 8 this returns: 10/30/1998 11:00:00 PM
.NET2
Under XP this returns: 10/31/1998 12:00:00 AM
Under Windows 7/Windows 8 this returns: 10/31/1998 12:00:00 AM
WHY??!?
Removing the TimeZone (the -04:00) from the string causes the value to be the same on both XP and Windows 7 under .NET4. It appears that Windows XP applies the timezone offset differently under .NET4 when doing a DateTime.Parse from the string. Is there some way to change this behavior so that it is consistent under .NET4, reguardless of OS (that does not involve manipulating the string being sent into DateTime.Parse)
Environment:
All machines have the latest patches installed (available via Windows Update) and are configured to Eastern Time with the ‘Automatically adjust clock for Daylight Savings Time’ checked in the ‘Time Zone Settings’.
I have confirmed this behavior on both a Windows 7 machine with .NET4 and a Windows 7 machine with .NET4.5
Calculating the local time for historical dates requires .NET knowing the daylight savings time rules that were in effect during that date. That’s of course a pretty tricky thing to do since DST rules vary a great deal across localities and dates.
Your date has a UTC offset of -4 which puts it somewhere close to the Eastern timezone in the USA. The most relevant DST rule change there was the 2005 Energy Policy Act which extended the period that DST is in effect from the 2nd Sunday in March to the 1st Sunday in November, effective in 2007. So knowing the local time in October 31st, 1998 requires knowing that this law was not yet in effect.
And that’s where the difference comes from. Windows Vista was the first Windows version that has a database of these DST changes, .NET 4 was the first .NET version that started using it. XP doesn’t have that database so .NET cannot do anything but assume that current DST rules are in effect.
This is the inevitable lossage you need to deal with when working with local time. Don’t, use UTC.