>This is just my frustration with FoxPro, but in the late 1990s when I worked at MS as a contractor in the FoxPro group I put in an Enhancement Request to have a new DateTime data type that included milliseconds.
>
>I talked to Calvin H. about it and he told me and it is well known that the VFP DateTime data type takes 8 bytes and that it certainly could contain milliseconds.
>
>A few years later I was working at a different shop and I needed to grab some data from SQL Server using VFP based on an exact DateTime value. Well, our SQL Server DBA was a real jerk and he was making a ton of money and I told him that VFP could easily pull this data. Anyway, because the VFP DateTime doesn't have milliseconds I failed miserably.
>
>I immediately put in another ER to Microsoft, but sadly as we all know they never did anything about it.

Actually for a while (version 5 or 6) the datetime fields did take milliseconds, but you couldn't display them. You'd have to do a dtField-ctot(ttoc(dtField)) to see the difference. Since it never displayed, we all thought the milliseconds weren't there, and wondered why queries on dtField=dtValue find almost nothing (or one in thousand, on the average). Since the display and literals with milliseconds (as in {^2018-01-02 13:04:15.345}) were never written, the simplest thing to do was to just truncate milliseconds off datetime values and thus make those queries work.

Ditto for the Y10K problem which won't be fixed - again, you can store a five-digit year, but can't display it.. try this:

CREATE CURSOR x (y t)
INSERT into x values ({^9999-12-31 23:59:59}+20000)
?y
?y-5000000