>>>>>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.
>
>Ok, that makes sense that the fractional seconds are actually stored in the data, but are not displayed or used in computations in FoxPro.
>
>In fact, that makes sense after my discussion with Calvin H. where he told me that certainly the 8 bytes of data stored could hold those fractions. But the thing with Calvin was he was so shrewd that he probably or certainly knew that the fractional data was already stored in the 8 bytes because he mentioned some kind of EE format, but he probably wanted to keep that a secret from me so that they wouldn't have to change it or expose those fractional seconds by using a SET command. I think it was decided in VFP 3 when the datetime FoxPro datatype was introduced that it would not contain fractional seconds in terms of display and computation. Actually, when they created VFP3 neither Calvin or I worked at MS.
>
>Who knows?????

Yes, it always had those fractions and were documented as I remember. One thing that I never liked is the datetime formats used within the Microsoft itself did not follow the same storage format (Datetime in VFP, in MS SQL and also file system file times ...). They were basically all made up of two 4 bytes of values but second 4 bytes did not mean the same thing in all :( One accepts it as mills from midnight, one as a fraction of the day, and MS SQL as ticks from midnight where each tick is 3.33 milliseconds. And here is my function to convert the file time (that one is float where decimal part is fraction of day) to a datetime:

Function Num2Time
Lparameters tnFloat
Return Dtot({^1899/12/30}+Int(m.tnFloat))+86400*(m.tnFloat-Int(m.tnFloat))

I also find it funny for file system epoch is 1899/12/30, while for SQL server it is 1900/1/1. What a consistency between the MS teams.

I understand they all wanted to be clever in storage but man, one could simply store date part in 3 bytes (covering 8192 BC and AC) and precisely storing the time part down to milliseconds take less than 32 bits. I learned all these the hard way, because datetime has a very important role in our flagship application < s >.

PS: Dragan put it better, the first time I discovered that when, visually same, date times were failing in equality check and I needed to make the comparison after converting both sides to a string (ttoc(,1) - yyyyMMddHHmmss). That may also have role in why MS SQL server queries containing datetime parameters start to work very slow after some time and you need to recompile the query.