DateTime precision?

Question

(ignoring the optimized compiler flag )

can it be that this code will enter the block on some systems ?

if (Datetime.Now!=Datetime.Now)
{
 ...
}

I mean , how does it evaluate the values here ? (is it by order) ?

Is there any situations where the condition might be true ?

again , ignore the optimized flag.

On a really slow system I guess. You just need a 1 tick stall between the calls to make them different. — leppie, Nov 06 '12 at 11:11
I loved this answer http://stackoverflow.com/a/2143784/570150 — V4Vendetta, Nov 06 '12 at 11:13
@leppie where "tick" means the system timer running, and not the `Tick` unit that represents 100ns. — CodesInChaos, Nov 06 '12 at 11:13
@CodesInChaos: No, I meant the latter. Or at least some form of it rounded, eg `49.9ns vs 50ns` — leppie, Nov 06 '12 at 11:15
@leppie Write a test program, and you'll see that it'll only change every 1-16ms on a typical windows system. — CodesInChaos, Nov 06 '12 at 11:19
@leppie a typical value is `23:59:59.9999999` and is much smaller than 1-16 ms... ( the 9999999 ).... no? — Royi Namir, Nov 06 '12 at 11:22
@RoyiNamir It displays those digits yes, but you'll see that they don't change individually. They'll stay the same until the millisecond part changes. — CodesInChaos, Nov 06 '12 at 11:26

score 5 · Answer 1 · answered Nov 06 '12 at 11:10

5

DateTime has a precision of 100ns. But on typical implementations, DateTime.Now only changes every few milliseconds.

Datetime.Now != Datetime.Now can be true, but it's extremely unlikely to happen. This is a typical race conditions of the kind you often see in multi-threaded code. i.e. you should not rely on DateTime.Now not changing, but rather store a copy in a local variable.

answered Nov 06 '12 at 11:10

CodesInChaos

106,488
23
218
262

is it related to computer frequency clock somehow ? – Royi Namir Nov 06 '12 at 11:10
It's related to an internal system timer which affects timers, `Thread.Sleep`, `DateTime.Now`, `Environment.TickCount`, thread switching,... – CodesInChaos Nov 06 '12 at 11:12
If i remember correctly `DateTime.Now` is relatively expensive since it uses IO. Another reason to store a copy. Edit: Here's the link i'm referring to: http://stackoverflow.com/q/10899709/284240 – Tim Schmelter Nov 06 '12 at 11:17
1

@TimSchmelter It's expensive because it needs to do time zone conversion. AFAIK the actual time getting part is rather cheap. On my comp `DateTime.UtcNow` costs 9ns, `DateTime.Now` costs 900ns. – CodesInChaos Nov 06 '12 at 11:20

score 4 · Accepted Answer · edited May 23 '17 at 12:06

DateTime.Now calls internally :

public static DateTime Now
{
    get
    {
        return DateTime.UtcNow.ToLocalTime();
    }
}

which calls internally:

public static DateTime UtcNow
{
    get
    {
        long systemTimeAsFileTime = DateTime.GetSystemTimeAsFileTime();
        return new DateTime((ulong)(systemTimeAsFileTime + 504911232000000000L | 4611686018427387904L));
    }
}

where GetSystemTimeAsFile is WindowsAPI function that return system clock information. The accurasy depends on system, so.

If you have a delay, for some reason between different gets (DateTime.Now ) it may produce different enough result that equality comparer fails. But I, personally, never met this kind of condition in my experience.

well, no :) if someone would ask a question like this, I can give only **guesses**, don't know what the guy in front will figure out about me after this :) — Tigran, Nov 06 '12 at 11:35

DateTime precision?

2 Answers2