Why datetime cannot compare?

Question

my C# unit test has the following statement:

Assert.AreEqual(logoutTime, log.First().Timestamp);

Why it is failed with following information:

Assert.AreEqual failed. Expected:<4/28/2010 2:30:37 PM>. Actual:<4/28/2010 2:30:37 PM>.

Are they not the same?

Update:

Use this if you only care to second:

Assert.AreEqual(logoutTime.ToString(), log.First().Timestamp.ToString());

Maccarthy

Are you sure the two values are equal? Maybe the millisecond parts are different? – Literalism

Check out #364555 apparently while the dates are equal that doesn't mean they are equal down to the tick. – Immaterialize

Answer 1

Have you verified that the number of ticks/milliseconds are equal?

If you do DateTime.Now() twice back to back, they will appear to be the same number down to the minute and probably even down to the second, but they will often vary by ticks. If you want to check equality only to the minute, compare each DateTime only to that degree. For information on rounding DateTimes, see here

---

A note about resolution:

The Now property is frequently used to measure performance. However, because of its low resolution, it is not suitable for use as a benchmarking tool. A better alternative is to use the Stopwatch class.

Fuqua

Answer 2

Try something like Assert.AreEqual(logoutTime.Ticks, log.First().Timestamp.Ticks)

Beauharnais

As Jon Skeet says on jlech's answer: "That will do exactly the same thing, other than showing the different values of ticks in the exception message." – Fuqua

Exactly, so it will show you why the two values aren't equal. – Beauharnais

Answer 3

The Assert fail method is probably calling ToString() on the DateTime which returns a truncated, human-readable form of the date without the milliseconds component. This is why it appears they are equal when, in fact, the DateTime object has a precision of a 100-nanosecond unit (known as a Tick). That means it is highly unlikely two DateTime objects will have the exact same value. To compare you probably want to truncate the value, perhaps by formatting the date to the fidelity you require.

Metcalfe

Answer 4

Using entity framework, if you fetch from the database using .AsNoTracking() the DateTime property will be rounded ever so slightly, whereas it won't necessarily be rounded without .AsNoTracking() if the original value is still in memory. Thus for integration tests involving a round-trip to the database, I guess it's best to use .ToString() because the database will reduce the precision slightly.

Lynlyncean

Answer 5

Are you sure that logoutTime and log.First().Timestamp are both typed as DateTime?

If so, they might also have different values for the more specific time infomation (e.g., milliseconds).

Carlyncarlynn

Answer 6

While working on unit test, I found below steps very useful to compare some date with mock date.

Mock date field as below:

mockDate = new DateTime(2020, 10, 10)

Call service method.

Assertion can be done like this:

Assert.AreEqual("10/10/2020 12:00:00 AM", _service.startDate.ToString());

Note while doing assertion:

• We have to provide date like : 10/10/2020 12:00:00 AM
• Then on service method date item we need to apply ToString(), this will convert date time into string value for comparison

If we just have to do assertion with datetime today date

Assert.AreEqual(DateTime.Today, _service.startDate);

Shortwinded

Answer 7

Assuming that logoutTime and log.First().Timestamp are both of type DateTime, you should try using this instead:

Assert.AreEqual(logoutTime.Ticks, log.First().Timestamp.Ticks);

Yolondayon

That will do exactly the same thing, other than showing the different values of ticks in the exception message. – Sapro

Answer 8

Since 2018 XUnit supports DateTime comparison within a given precision:

Assert.Equal(DateTime.Now, myObject.CreatedAt, TimeSpan.FromSeconds(1));

Jocund

Answer 9

I suppose Assert.AreEqual<T> uses Object.Equals() to determine equality of the objects but not the values.

Probably this statement is comparing two different objects and therefore is returning false.

Carbuncle