Re: What does Time.MAX_VALUE actually represent?

Moin,

On Sun, December 31, 2017 12:50 pm, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> select timestamp '2017-12-30 24:00:00';
>> returns
>> 2017-12-31 00:00:00
>> which makes some sense.
>
>> I don't know why we accept that and not '24:00:01' and beyond, but it's
>> probably historical.
>
> We also accept
>
> regression=# select timestamp '2017-12-30 23:59:60';
> timestamp
> ---------------------
> 2017-12-31 00:00:00
> (1 row)
>
> which is maybe a little bit more defensible as a common behavior
> to allow for leap seconds. (It's far from a correct implementation of
> leap seconds, of course, but I think most versions of mktime() and
> friends do likewise.)
>
> Digging into the git history, it looks like this choice dates to
>
> commit a93bf4503ffc6d7cd6243a6324fb2ef206b10adf
> Author: Bruce Momjian <bruce(at)momjian(dot)us>
> Date: Fri Oct 14 11:47:57 2005 +0000
>
> Allow times of 24:00:00 to match rounding behavior:
>
> regression=# select '23:59:59.9'::time(0);
> time
> ----------
> 24:00:00
> (1 row)
>
> This is bad because:
>
> regression=# select '24:00:00'::time(0);
> ERROR: date/time field value out of range: "24:00:00"
>
> The last example now works.
>
>
> There may at the time have been some argument about imprecision of
> float timestamps involved, but it works the same way today once
> you exceed the precision of our integer timestamps:
>
> regression=# select time '23:59:59.999999';
> time
> -----------------
> 23:59:59.999999
> (1 row)
>
> regression=# select time '23:59:59.9999999';
> time
> ----------
> 24:00:00
> (1 row)
>
> If we didn't allow '24:00:00' as a valid value then we'd need to
> throw an error for '23:59:59.9999999', which doesn't seem nice.

Hm, but shouldn't the result then be "00:00:00" instead of "24:00:00"?

With addition it seems to work different:

postgres=# select time '23:59:59.999999' + interval '0.000001 seconds';
?column?
----------
00:00:00
(1 row)

Best regards,

Tels