It is THEORETICALLY possible for a date/time variable to hold milliseconds, but the Access standard date/time formatting routines will not recognize the fractions of a second and the Now() function will not give you fractional times. Since a DATE variable is a typecast of a DOUBLE, you have 53 bits of mantissa to play with. You need approximately 16 bits for the date (up to a time in the future in I think the 32nd century) and you need 17 bits for the time of day. That leaves 20 bits unaccounted for. If you track time to milliseconds, you have to use another 10 bits. Due to rounding effects, the last 10 bits of the mantissa cannot be used reliably.
I have made this "extended time" work many years ago when dealing with computation of specific network timing issues based on log files (from another source) that contained the times to that precision. I can't show you any code because it was a database I did not own and so could not keep a copy.
You cannot use the standard Access routines at ANY point when converting between formatted text and the date/time variable. Basically, I used some parsing options to split apart the date in dd-mmm-yyyy format OR mm/dd/yyyy format. I could tell which one I had by searching for the dash and slash. After that, I picked out the time in hh:nn:ss.fff format to hours, minutes, seconds, and fractions based on the colons and dots. Then I used simple multiplication and division to build the DOUBLE. Of course, going the other way, the date part is just an integer and the fraction part can be repeatedly divided by the various factors for hours, minutes, seconds, and milliseconds.
As long as you don't send the DATE variables through anything that would try to format the variable, they will retain the fractions and you can even do math on them. But remember, you can NEVER get native Access to handle that fraction of a second.
