4

What is the minimum time you need to Thread.Sleep( ) to ensure DateTime.Now differs ?

Given a DateTime has a Ticks property you could argue the following would suffice: 

Thread.Sleep(TimeSpan.FromTicks(1));

which would be fine but does this guarantee subsequent calls to DateTime.Now are not equal?

UPDATE: Appears DateTime precision is hardware dependent so instead I am going to use the following method:

public static void SleepUntilDateTimeChanges()
    {
        DateTime now = DateTime.Now;
        while(now == DateTime.Now)
            Thread.Sleep(TimeSpan.FromMilliseconds(1));
    }
wal
  • 17,409
  • 8
  • 74
  • 109
  • 1
    This has a bad code smell about it. Can you explain why you are doing this strange thing in the first place? There is probably a better way to solve your problem. – Eric Lippert Oct 13 '10 at 05:08
  • 1
    Yes, it is for a test case. I need to make sure a DateTime property used to represent a timestamp is not updated when something happens. So, I have some code AssertAreEqual(date1, date2); however I need to be sure this doesnt pass simply because the test runner ran really fast. I must admit the code as it stands smells a bit but in the context it is used it is ok. I didnt want to put Sleep(100) everywhere as it slows the test runner down. – wal Oct 13 '10 at 05:41
  • Thread.Sleep has a resolution about 30-50 milli seconds. Sleeping less then that is usually nonsense. You're better of using a high frequency timer and waiting 1 millisecond tick or use a better time container then a DateTime. – CodingBarfield Jan 11 '12 at 12:32
  • was doing the same. see also: http://stackoverflow.com/questions/508208/what-is-the-impact-of-thread-sleep1-in-c – nawfal May 20 '13 at 19:14

1 Answers1

6

A "tick" is 100 nanoseconds. Or 1/10,000th of a millisecond. Thread.Sleep operates on milliseconds. While it's true it accepts a TimeSpan, a value less than a millisecond will be ignored (i.e. same as zero). According to @wal the resolution of only 10 milliseconds can be guaranteed. If you wait that amount you should get unique DateTime instances.

See also this explanation by Eric Lippert which sheds some more light on DateTime precision.

Community
  • 1
  • 1
Kirk Woll
  • 76,112
  • 22
  • 180
  • 195
  • Thanks for the link. Someone posted: "From MSDN you'll find that DateTime.Now has an approximate resolution of 10 milliseconds on all NT operating systems." so I am going to use the method posted in my Update (above) – wal Oct 13 '10 at 01:05
  • Kirk, can you edit your answer 'if you wait a full millisecond' as that may not turn out to be true given the info on the link you sent. I can then accept your answer. :) – wal Oct 13 '10 at 03:27
  • Kirk, Sorry. The resolution of 10 ms cannot be guaranteed, it is hardware specific (according to that link). Cheers. – wal Oct 13 '10 at 04:59
  • 1
    See also http://blogs.msdn.com/b/ericlippert/archive/2010/04/08/precision-and-accuracy-of-datetime.aspx – Eric Lippert Oct 13 '10 at 05:11