Bug 1055 - DateTime.Now occasionally returns incorrect time (off by an hour)
Summary: DateTime.Now occasionally returns incorrect time (off by an hour)
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 2.10.x
Hardware: PC All
: High critical
Target Milestone: Untriaged
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2011-09-26 11:48 UTC by Andrew Buchanan
Modified: 2012-01-06 17:05 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Test app/code you can run to reproduce issue. (25.77 KB, application/octet-stream)
2011-09-26 12:10 UTC, Andrew Buchanan
timezone-lock.patch (1.02 KB, patch)
2011-09-28 11:58 UTC, Jeffrey Stedfast

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Andrew Buchanan 2011-09-26 11:48:43 UTC
I have a system that calls DateTime.Now in the range of 300-1500 times a second. (a Video recorder, time-stamping received packets)

Over the course of an hour period I have observed that DateTime.Now will be off by exactly one-hour for about 1 minute, and then return to the correct time.  It happens about 2-5 times an hour.

It looks to me like something fails to get the daylight savings offset properly and caches an incorrect value for about 1 minute. That's purely a guess but it looks that way.

I have observed this behavior on several machines running fedora 13 that I've built and compiled mono 2.10.5.  The problem did not exist with mono 2.6.4 which is the version they were previously running.  I have a vm running fedora 12 in hyper-v (single cpu) that doesn't seem to have the issue, so I suspect it may be a multi-core/locking issue as well.
Comment 1 Andrew Buchanan 2011-09-26 12:10:45 UTC
Created attachment 497 [details]
Test app/code you can run to reproduce issue.

Run the code for an hour or so on an affected machine and you should have some red printouts showing the datetime has gone backwards and then forwards again.

I'm guessing it's Daylight savings related.  I'm in Mountain Standard Time, so I suppose depending on your time-zone and whether you're currently in daylight savings when you run the program, as well as perhaps if your system clock is UTC or Local probably all could play a role.
Comment 2 Jeffrey Stedfast 2011-09-26 13:18:16 UTC

Probably needs some sort of locking.

If you've got the time to setup a local build of Mono, you could try putting locks around in TimeZone.get_CurrentTimeZone and DateTime.get_Now and see if that solves things. I suspect it will.

Otherwise I'll look at this closer as soon as I get some spare time.
Comment 3 Jeffrey Stedfast 2011-09-27 16:45:47 UTC
Running this now but so far no red error messages.

I should probably point out that relying on DateTime.Now for time-stamping audio/video frames is probably not a good idea as it is not guaranteed to be accurate to anything more than 1 minute (which doesn't sound accurate enough for your needs).
Comment 4 Jeffrey Stedfast 2011-09-27 16:53:29 UTC
Actually, n/m, I'm wrong. It's only caching the timezone diff for up to one minute (I misremembered it caching the actual DateTime.Now value up to one minute)
Comment 5 Jeffrey Stedfast 2011-09-28 11:58:00 UTC
Created attachment 522 [details]

I wasn't able to reproduce with Mono 2.10.6 after letting it run for the past 24 hours.

Attached is a patch that may solve the problem for you (if the problem is what I think it is), but since I can't reproduce even without the patch, I have no way of knowing if it does or not.

Can you confirm whether or not this fixes things for you?
Comment 6 Andrew Buchanan 2011-09-28 15:29:54 UTC
I'll try out your patch as soon as I can, probably tonight or saturday.
I have several machines I can reproduce it on fairly easily (and another I can't).
Comment 7 Jeffrey Stedfast 2011-09-28 15:34:23 UTC
Might be interesting to note when it gets screwed up (e.g. is it when UTC time rolls over to the next day?)
Comment 8 Andrew Buchanan 2011-09-29 09:10:26 UTC
The patch appears to fix the issue for me. 

I don't think it has anything to do with the UTC day rolling over, I found it happened several times an hour.  I see you locked the implementation of CurrentSystemTimeZone, so it must be something in there.

Not sure if you want to mark it as resolved or what to look into it further?  I will leave my test running today to see if it occurs, but I ran it for 5 hours last night with no issues and I used to have several per hour.
Comment 9 Jeffrey Stedfast 2011-09-29 10:58:12 UTC
Okay, thanks... I'll commit my patch to the 2.10 branch & master for inclusion in a 2.10.7 release.

If at some point the bug pops up again, report back here/reopen and I'll dig into it further :-)
Comment 10 Paolo Molaro 2011-09-29 11:32:48 UTC
You should use Stopwatch to do packet timestamping, as that is actually a monotonic clock (DateTime can change forward or backwards, depending on timezone, but also on the user setting the time manually or using a time server and ntpd etc)
Comment 11 Andrew Buchanan 2011-09-29 12:13:09 UTC
Yeah... I realized DateTime.Now wasn't the right thing to use once this happened, but I figured I should still report the bug.  I switched to DateTime.UtcNow as it avoids most of the issues and was easy to switch out.  I never considered using stopwatch for anything other than benchmarking :-), I'll look into that as your correct about ntpd/etc.
Comment 12 PJ 2012-01-06 17:05:33 UTC
Verified fixed on:

Mono for android 4.0.1
Windows 7

Closing bug as fix is in production.