Objo DateTime resolution

bgrommes

I presume that Objo's DateTime type is backed by .NET's DateTime type.

The latter is a 64 bit type that consists of a 62-bit integer representing the number of ticks (100 nanosecond increments) since Jan 1, 1 AD, plus a 2-bit DateTimeKind enumeration (LocalTime, UtcTime, Undefined).

Objo does not expose either the ticks or the enumeration in either DateTime or Duration. Which is fine for my purposes, and I suspect most people's purposes. Millisecond resolution is fine so far as i'm concerned. I presume it just uses the LocalTime default for the "kind".

However, I'm wondering if Objo explicitly drops the ticks when initializing a new DateTime or might pick them up at times, say, from DateTime.Now. If yes, then it's possible that subtracting or adding to/from datetimes could carry any nonzero ticks forward, and might cause the occasional 1-millisecond drift. Probably more of an issue would be that it could (depending on how equality is tested) result in two seemingly identical DateTimes not being equal.

My preference would be that Objo guarantees that any nonzero ticks are dropped, or at least ignored. But mostly this is just a curiosity question on a pretty fine point, admittedly.

Garry

Good question. Your concern is valid, and the current implementation has a slightly different answer from the one you presumed.

Objo’s DateTime deliberately does not retain .NET’s DateTimeKind. It is a timezone-naive wall-clock value, so a value obtained from either DateTime.Now or DateTime.UtcNow has no stored Local/UTC kind afterwards.

However, Objo does preserve the complete .NET tick count, including ticks below one millisecond. DateTime.Now, parsing and host APIs such as files and databases can therefore introduce sub-millisecond precision. Add, Subtract, equality, ordering and hashing all use that complete value.

That means two DateTimes can display the same millisecond while still comparing unequal. It isn’t really arithmetic drift (the original fractional value is being preserved) but the precision was insufficiently visible through the API.

I’ve made this explicit and controllable for the next release:

DateTime.Ticks returns the exact number of 100-nanosecond ticks.
DateTime.FromTicks(ticks) reconstructs an exact value.
date.TruncateToMilliseconds() returns a value with any sub-millisecond ticks discarded.

I decided not to discard those ticks automatically because Duration also has 100-nanosecond precision and DateTime.Add(Duration) and Subtract should remain exact. Callers wanting millisecond-resolution identity can now request it explicitly:

Var precise As DateTime = DateTime.Now
Var milliseconds As DateTime = precise.TruncateToMilliseconds()

Incidentally, the current Duration API exposes its exact value through Duration.Ticks and can construct one with Duration.FromTicks().

The change is tracked here: Make DateTime tick precision explicit and controllable and will be in the next release.

bgrommes

Garry TruncateToSeconds() and TruncateToMinutes() would also be useful. For example, Sql Server has a smalldatetime type that drops seconds / milliseconds / ticks. Another example: in one of my systems, I dynamically create folders to hold data submitted as of a certain time and I truncate that to just hours and minutes as it keeps the name smaller and the resolution is completely sufficient. To do that in .NET, I have to resort to newing up a DateTime from a more precise DateTime with seconds set to zero, or hide that behind an extension method that specifies precision.

Arguably even more useful than the above would be TruncateTime() or TruncateToDateOnly() since you very often need just the date component and Objo doesn't expose a DateOnly type. Before DateOnly was introduced in C#, I was clipping the time component all the time (pun slightly intended).

Honestly I find the API for DateOnly to be a bit clunky (although I've gotten used to it) so I'm not advocating for that exact type in Objo really. Just a quick way to lose the time piece when desired.

Garry

Good suggestions. I’ve expanded the change for the next release with:

TruncateToSeconds()
TruncateToMinutes()
TruncateToHours()
A read-only Date property

The truncation methods return a new DateTime, always discard the lower-resolution components without rounding up, and leave the original value unchanged.

Date returns another DateTime representing the same calendar date at midnight. This provides the useful date-only behaviour without introducing a separate DateOnly type:

Var precise As DateTime = DateTime.Now
Var folderTime As DateTime = precise.TruncateToMinutes()
Var day As DateTime = precise.Date

The completed change is tracked here. Thanks for the useful follow-up.