Re: regression failure - horology

In article <12354(dot)1045901353(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Joe Conway <mail(at)joeconway(dot)com> writes:
>> Tom Lane wrote:
>>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>>> (also HPUX 10.20). Are you using default config, or
>>> --enable-integer-datetimes?
>
>> I'm using --enable-integer-datetimes on both.
>

It looks like the regression checks need to use two different formats
depending on if integer-timestamps is being used.

For the normal floating point timestamps, the regression checks are correct
since all timestamps between 4713BC to 5874897AD.

However using a 64 bit integer to represented as number of microseconds since
Jan 1, 2000 gives the following reduced range of 4713BC to about 294277AD.
In order to represent to full range of timestamps for julian day counts from 0
to 2147483647 to the nearest microsecond, you require:
31 bits for the day
17 bits for the second
20 bits for the microsecond
for a total of 68 bits needed to represent the full range of timestamps to
the nearest microsecond.

Suggested fix would be one or more of the following:
1. Reduce the range tested within the regression checks to what is
capable for integer timestamps.
2. Use two different regression checks depending on if integer timestamps
are in use.
3. Document the different ranges for timestamps depending on if integer
timestamps are in use.