>It uses a 64-bit floating point format when stored to a disk file. If it is the same in VFP then you could convert it using similar code through a custom DLL, or clever use of the printf() functions.

Once upon a time I wrote a crashed table rebuilder, and that included reading dbfs by means of LLFF, reading rows as strings, chopping them into field-length strings and then extracting values from these strings. Learned a lot of interesting stuff while doing that. Among other formats, I had to dig into datetime as well, and it's actually two 4-byte integers: one to hold the Julian date number, and the other to hold the number of milliseconds.

Now at some point VFP stopped storing these milliseconds, because you couldn't seek() such values. You'd browse a table, assign a value of a datetime field to a variable, and the variable wouldn't be equal to the field value, because it was rounded. Or you scanned for a range of datetime values, and you'd get an odd record on either end at the wrong side of the range, because the values weren't what you saw - they included milliseconds you couldn't see (unless you subtracted the visible value from the field value, just like you described). It was messy and caused lots of bugs and grey hairs. The internal format is fine - it's just that Fox was never able to display these milliseconds, which it could store. Same situation on the other end - since the date portion is an integer, it can store dates up to 2 billion dates since year 1, but it can't display them, so they are internally forbidden (considered invalid values) and we're forced to live with the Y10K bug.

Haven't checked this for a few last versions of Fox (and specially not in conjunction with SQL server), but I think the milliseconds were dropped. Want to store datetime to your desired precision? Use a date field and a n(9,3) field to store seconds(). Or a datetime and an n(3) where you'd store just milliseconds.