Crystal, not what I meant.
DOUBLE gives you a 53-bit mantissa. The time-line method used by Access and Excel treats time (in the abstract) as a linear domain in units of days and allowing fractions thereof. The integer portion of days allows easy conversion of a number of days to a date based on the Epoch date. This algorithm has been known since the 1960s at least. Maybe longer. The fractional approach allows you to convert time as a fraction of a day. But if you look at the storage requirements, ...
The current date is somewhere in the 40,000s range, which requires no more than 16 bits ( < 64K days). A time requires 86,400 discrete ticks to represent seconds, which is no more than 17 bits ( < 128K seconds.) That's 33 bits consumed by date and time to the second. You've got 20 bits left over in the mantissa. UTC requires you to reach millisecond timing when doing certain precise networking operations, such as Network Time Protocol. So change seconds to milliseconds and you consume another 10 bits (=1K) of that mantissa. You STILL have 10 bits to help with and guard against the inevitable rounding associated with fractions that contain odd-number factors.
My comment is merely that based on the idea of a Date/Time Extended data type, they might get by with a new set of representational routines, like an extended time code to show fractions of a second. I wonder if they are going to tie into the high-precision internal clock that has been on Intel systems since the advent of the Gigahertz backplanes. I've looked it up - the fast clock IS present in WinServer 2000 and Windows Vista and later.
Windows provides APIs that you can use to acquire high-resolution time stamps or measure time intervals.
docs.microsoft.com
You are worried about rounding issues and I get that. But my comments were about capacity, not representation. The way OpenVMS does it is not significantly different and that is a server-class O/S. They use a 64-bit integer with units of JIFFIES (=0.1 microsecond). But the problem is always the same. Past a certain point, you get lost in the low-level bits WHATEVER you choose as a representation. Which is why I agree that you need some type of bounding function - like ROUND() or FIX() or perhaps convert it to a string date and compare in
yyyy-mm-dd hh:nn:ss format, where the strings would compare correctly for equal, less, or greater.