On 7-8-2014 16:28, Lester Caine lester@... [Firebird-general] wrote:

> On 07/08/14 15:01, 'Paul Beach' pabeach@... [Firebird-general]
> wrote:
>> Also
>> https://www.ibphoenix.com/resources/documents/design/doc_185
>
> That throws up another question :(
> 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 ...

The resolution is 100 microseconds (1/10000 of a second). I can't
imagine having to work with a fraction of a day.

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

Leap seconds are applied at the end of the day.

This means that on normal days the maximum value is
10000 * 60 * 60 * 24 = 864000000
On leap-second days the maximum should be 10000 higher 864010000.

This is purely theoretical as I don't know how Firebird actual handles
leap seconds (if at all).

Mark
--
Mark Rotteveel