>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.

Ah, and the number of days since 1899/12/30 with fractional time is pretty much what we see in Excel and LibreOffice Calc. I just tried to type a random number with decimals into a column formatted as a date, and sure enough got a datetime displayed. Typing 1 gave 1899/12/31, -456,78901 gave 29.09.1898 05:03:50.