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

> 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

What do you mean with "date.5 and date.25 I get 6pm"? Are you talking
about doing someDate + 0.5? That works in day fractions because that is
how the date/time arithmetic is defined (see
https://www.ibphoenix.com/resources/documents/design/doc_185 curiously I
wasn't able to find anything about this in the normal documentation),
the end result however is still a time part in 100 microsecond units.

Maybe I should have better qualified my previous comment: I can't
imagine having to work with day fractions *when having to calculate an
exact time*.

> 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

As far as I know, the 100 microsecond resolution is nothing new (or at
least has existed since Interbase 5 or earlier), however a lot of
libraries etc don't expose it (neither does Firebird itself in some
situations like converting to string).

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

Yes, potentially.

Mark
--
Mark Rotteveel