On 07/08/14 15:48, Mark Rotteveel mark@...
[Firebird-general] wrote:

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

That is exactly how numeric calculations on timestamps are carried out?
If I add date.5 and date.25 I get 6pm in the result
I multiply the fraction by 86400 I get the number of seconds. I have
material stored long before the finer resolution came about and that
works fine even today. I've always worked on that basis

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

It is the conversion between fractions and seconds that this would affect?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk