Home Dashboard Directory Help
Search

.NET 4 DateTime.ToLocalTime() is sometimes wrong by BricknerB


Status: 

Closed
 as Fixed Help for as Fixed


1
0
Sign in
to vote
Type: Bug
ID: 559198
Opened: 5/14/2010 8:07:17 AM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I've recently upgraded my code to Visual Studio 2010 and .NET 4.0.

This code fails on the third Assert instead of the second Assert:

            TimeZone zone = TimeZone.CurrentTimeZone;
            Assert.AreEqual("Jerusalem Standard Time", zone.StandardName);
            DateTime date = new DateTime(2004, 08, 25, 10, 35, 0, DateTimeKind.Utc);
            date = date.ToLocalTime();
            Assert.AreEqual(new DateTime(2004, 08, 25, 12, 35, 0, DateTimeKind.Local), date);
            Assert.AreEqual(new DateTime(2004, 08, 25, 13, 35, 0, DateTimeKind.Local), date);

Converting UTC time August 25th, 2004 to Jerusalem Standard Time should give the hour 13 and not the hour 12.

Look at the world clock:

http://www.timeanddate.com/worldclock/converted.html?month=8&day=25&year=2004&hour=10&min=35&sec=0&p1=0&p2=110

This happens in a lot of dates but not in 2010.
Details
Sign in to post a comment.
Posted by Microsoft on 6/14/2010 at 9:13 AM
Since this data hasn't been corrected yet, having an updated OS won't matter. When a fix is ready it should be available via windows update - althought I have no ETA for that.

If you need something in the meantime, you could try writing the adjustment rules yourself. See http://msdn.microsoft.com/en-us/library/bb397784.aspx

Hope that helps.

Matt Greig
BCL Team
Posted by BricknerB on 6/10/2010 at 10:34 AM
I still experience this bug (I have an updated OS).

How can I be updated when the bug is fixed?
Posted by Microsoft on 6/4/2010 at 12:06 AM
Hi,

Thank you for reporting this issue. This is indeed a serious problem.
However, the cause for this issue is not within the .NET framework. The problem lies within the Windows database that .NET must query to find out about local daylight saving time rules.

You can see this behaviour directly in Windows: Set up your system tray to show two clocks - one UTC and the other Jerusalem local time. Set your date to the 25 of August 2010. You will see that the time difference is correct (3 hours). Now set the date to the 25 of Aug 2004. The time difference is now 2 hours. If you are using an older version of Windows that does not support 2 clocks in the system tray, you can use one clock and simply switch your system location time between UTC and Jerusalem. In either case, however, make sure you use UTC, and not a local time of an area with a UTC+0 hours offset, because the local time is likely to undergo daylight saving time changes that may or may not be in sync with Jerusalem.

I will contact the Windows team and notify them of the problem, such that the DST database can be updated in a future Windows update.

I hope this helps!

Greg
Software Development Engineer on the BCL team
Posted by Microsoft on 5/16/2010 at 11:02 PM
Thanks for your feedback. We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 5/14/2010 at 5:04 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.