Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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.
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.
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).
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)
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?
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).
Might be interesting to note when it gets screwed up (e.g. is it when UTC time rolls over to the next day?)
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.
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 :-)
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)
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.
Verified fixed on:
Mono for android 4.0.1
Closing bug as fix is in production.