none
DateTime.Parse different on XP vs Windows 7 / 8 RRS feed

  • Question

  • 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

    Thursday, January 10, 2013 3:16 PM

Answers

  • The item marked as the answer in my StackOverflow thread is the cause. Basically, quoting the post:

    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.

    • Marked as answer by Art Gola Thursday, January 10, 2013 7:15 PM
    Thursday, January 10, 2013 7:15 PM

All replies

  • hi

    did you try

    DateTime.Parse("1998-10-31T00:00:00-04:00",DateTimeFormatInfo.InvariantInfo)
    ?


    Regards, Nico

    pdfaid, my blog

    Thursday, January 10, 2013 3:40 PM
  • Passing DateTimeFormatInfo.InvariantInfo into the DateTime.Parse has no impact on the results. 

    You may also want to edit your post as the code snippet you suggested is obscured with a scrollbar.

    • Edited by Art Gola Thursday, January 10, 2013 3:51 PM
    Thursday, January 10, 2013 3:49 PM
  • Are you in Standard Time or Daylight Saving time?  You should be subtracting 5 during the winter and 4 during the summer.

    jdweng

    Thursday, January 10, 2013 4:06 PM
  • Right now we are in Standard Time, however, regardless of the value I should be subtracting, I would expect both Windows 7 and Windows XP to produce the same result given a fixed string sent into DateTime.Parse if the machines are configured for the same timezone settings (which they are).  This is currently not the case; Windows 7 produces one value, and Windows XP a different value.
    • Edited by Art Gola Thursday, January 10, 2013 4:14 PM
    Thursday, January 10, 2013 4:10 PM
  • Make sue the windows time zone and "day light savings" setting are set the same.  You will get a difference if operating system is set wrong.

    jdweng

    Thursday, January 10, 2013 5:05 PM
  • I have confirmed that both machines are set to Eastern Time and both machines have the 'Automatically adjust clock for Daylight Saving Time' checked.  Additionally, the time as displayed by Windows is the same on both machines.



    • Edited by Art Gola Thursday, January 10, 2013 5:15 PM
    Thursday, January 10, 2013 5:10 PM
  • Does it happen in the year 2012 for the same date.  Time time we switch back and forth between Standard and Daylight time keeps on changing.  So I'm wondering if the year has something to do with the differences.

    jdweng

    Thursday, January 10, 2013 5:25 PM
  • Under .NET4 in both XP and Windows 7, this returns the SAME value -- which is what I would expect:

    Console.WriteLine(String.Format("Value of 2012-11-04T00:00:00-04:00: {0}", DateTime.Parse("2012-11-04T00:00:00-04:00")));

    The value returned is: 11/4/2012 12:00:00 AM

    • Edited by Art Gola Thursday, January 10, 2013 5:31 PM
    Thursday, January 10, 2013 5:30 PM
  • If you try a few more values you could probably figure out at what date it returns the wrong value.  It looks like a bug was fixed and wasn't incorpoated into the windows 7/8 source code.


    jdweng

    Thursday, January 10, 2013 5:47 PM
  • The item marked as the answer in my StackOverflow thread is the cause. Basically, quoting the post:

    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.

    • Marked as answer by Art Gola Thursday, January 10, 2013 7:15 PM
    Thursday, January 10, 2013 7:15 PM