>>>>You're welcome. One note about saying stores milliseconds. Actually not storing it as milliseconds but it's a real number keeping time as a fraction (terminology differs but result is same technically).
>>>>Cetin
>>>
>>>As a mather of fact, it IS stored in a millisecond format in the DBF. When it is used in memory it is in an floating-point format, giving rise to some rounding artifacts.
>>>
>>>(for the complete specs of how it is written to disk see my message in the newsgroup microsoft.public.fox.vfp.dbc on 22 jun 2003)
>>
>>On dbf:
>>

>>* someDatatetime
>>BINTOC(VAL(SYS(11,someDatatetime)),"RS"),BINTOC(Daymsec(someDatatetime),"RS")
>>

>>
>>On memory:
>>

>>floatvalue=VAL(SYS(11,someDatatetime))+DaySec/86400
>>

>>The problems are born because 1/86400 cannot be represented in base2.
>>
>>Only datetimes with DaySec=k*675 they are exactly stored on memory.
>
>Yes, I never understood the reasoning behind it to store milliseconds. In memory it could be:
>floatvalue=VAL(SYS(11,someDatatetime))+DaySec
>and there would be still space for a wider range of datetimes.
>Cetin

with float there is never issue to store a julian datetime
with 1 ms of precision.
Floating point precision is 53 bit,
julian day of year 10000 with 1 ms require 49 bits:

? ceiling(LOG(VAL(SYS(11,DATE(9999,12,31)))*86400000+86399999)/LOG(2))

and this
Is possible to store 0.1 ms exactly !

? ceiling(LOG(VAL(SYS(11,DATE(9999,12,31)))*864000000+863999999)/LOG(2))

the important thing it is that not to fall in the trap to consider the day as unity
and to make dsec/86400.
Unfortunately someone is fallen in the trap.