OK, here's the way I understand it.
Date variables are actually typecasts of type DOUBLE, and are the number of days since some reference date. It actually doesn't matter which one. What Access and Excel, and a couple of others really do is they have date formatters that read the DOUBLE and convert it from 39182.5423235663 into something that looks more like a date and time. In this standard, midnight is fraction 0.000, Noon is 0.5000, you can figure the rest of the times yourself.
The problem is in the formatter, which doesn't acknowledge that you could get a fraction of a second. It says your time is days and fractions since the reference, so it counts up the days, then figures the time by converting the fraction to seconds, and that's what you get.
The solution comes in two parts. First, your date source must never try to convert an existing date string into a date format. Because... the formatter truncates the other direction, too. If you give it a date and time to the second, that DOUBLE won't give you fractions. It will be the result of a computation that stopped at seconds.
The second problem is that you can't do this in one fell swoop. The "right" way would be to multiply the DOUBLE by 86,400 (seconds per day), truncate that to an integer, then perform a modulus function to extract the fractions separate. Unfortunately, if you take the current dates in Access and do that multiplication, the resultant numbers overflow a LONG integer. Whoops!
The only way I was able to solve this was to do a Julius Caesar on it. Divide and conquer.
First, figure out the day number by copying the date to a DOUBLE. Then use the FIX function to truncate that number to some integer. Then re-float that number to a DOUBLE again, subtract it from the copy of the date. What's left is a day fraction. OK, multiply THAT by 86,400. Use the FIX function again to convert to a LONG, then back to another DOUBLE, substract, and what's left are the fractions of a second.
OK, almost there... That number you have is fractions of a second, but to get that to something useful, you need to scale THAT back to an integer. Multiply it by 1000, use FIX on that, and use a leading-zero format to convert the number back to the range from 000 to 999.
Now go back and build your format by taking the original date, converting this using one of the standard formats that gives you date + hh:nn:ss, then concatenate that with a dot and your three-digit number. That gives you milliseconds.
And I'd advise you to not push farther than that, because you are running at the ragged edge of precision when you do that. You are already going to probably see a bit of blotchiness in the time continuum of that number. It's not that the number won't support that level of precision. It is that you very rarely have an internal system clock that is updated that precisely. If you just wanted to convert that fraction of a second to hundredths rather than msec, you are probably on better, though still not perfectly firm, footing.
I'd write a little function to do this in your desired format. Input would be a date field. Output would be a string.
