Lester wrote:

> I've always worked with the time element being a fraction of the day,
> but that states it's a count in 1/10000's of a second ...

That's correct. There are 864,000,000 of those thingies in a day, so that
makes them fit in a 32-bit signed integer.

With 1/100,000's of a second, you'd need 34 bits unsigned or 35 bits signed.

> Part of the reason I'm trying to document things is a discussion on leap
> seconds, and why 'our' system of working does not need to worry about an
> extra second on the odd day, but conversion to unix epoch is not so
> easy. Knowing which days have the extra second one can adjust, but when
> I'm working with the timestamp as a simple fraction what happens on
> those days if time element is stored as a number.

Actually, our system can handle extra seconds with ease. With fractional
days, if you assume that 1/86400 represents a second, and <fraction> *
86400 gives the number of seconds passed since midnight, this would be
'off' on days with a leap second.

OTOH, if you want to convert our decimilliseconds to a fractional day,
this will also be off on a leap second day.


Paul Vinkenoog