>>>Finally, one of my greatest disappointments is that FoxPro's datetime datatype does not include fractional seconds the way SQL Server does. Instead FoxPro just supports whole number seconds without a fractional part. Yet, the FoxPro datetime datatype is 8 bytes, which is more than enough to store fractional seconds. Heck, this new MSSQL Datetime2 is 8 bytes or less. I actually discussed this with Calvin H. and he said that it could be easily done. I put in an ER, but they never did anything about it. I suspect it would have required a new datatype with a name of its own. Remember that FoxPro dates are stored on disk as simple text, but datetime is binary data on disk. And an extended FoxPro datetime would be binary as well. Again, it would all fit easily into 8 bytes.
>>
>>That is not exactly correct. Foxpro's datetime datatype too does include fractional seconds and it does not just supports the whole numbers. Those fractions cause trouble, as they also do with MS SQL server's 3 ms sensitivity.
>
>How do you see or access these fractional seconds in the FoxPro datetime datatype? I just don't see it.

Instead of trying to access it as a datetime, you can access the table low-level, get the 8 bytes and decode (datetime is actually a display value in VFP, while it doesn't show the fractions, the fractions are there). Too many years back I posted here code demonstrating the issue. I just don't know how can I find my own codes here anymore. MS SQL server datetime also catch you more or less the same way. ie: 20180522 23:59.59.999 and 20180523 00:00:00.000 In SQL server are treated as same but should not be.

DECLARE @t1 DATETIME = '2018/05/22 23:59:59.999';
DECLARE @t2 DATETIME = '2018/05/23 00:00:00.001';

if  @t1 < @t2 
print 't1 is before t2'
ELSE
PRINT 't1 is NOT before t2';

PS: This is maybe the main reason why now datetime2 exists and encouraged, besides its range. It doesn't have this fractional problems.