>>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 >.
>
>Odd number of bytes? There were processors which didn't like that.

That is not a problem. For date they already used 4 bytes, simply could pad with byte(0) :)

Anyway, instead the path of unix might be chosen.

PS: Did you know that, if used from within VFP, VFPOLEDB doesn't know how to handle datetime :) Fun hour.