Regression failures: time, timetz, horology

Michael Fuhr <mike@fuhr.org> writes:

I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:

I'll bet a nickel this broke it:

2005-05-25 23:48 momjian

* src/: backend/utils/adt/datetime.c,
interfaces/ecpg/pgtypeslib/interval.c: Display only 9 not 10 digits
of precision for timestamp values when using non-integer
timestamps. This prevents the display of rounding errors for
common values like days < 32.

regards, tom lane

Tom Lane wrote:

Michael Fuhr <mike@fuhr.org> writes:

I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:

I'll bet a nickel this broke it:

2005-05-25 23:48 momjian

* src/: backend/utils/adt/datetime.c,
interfaces/ecpg/pgtypeslib/interval.c: Display only 9 not 10 digits
of precision for timestamp values when using non-integer
timestamps. This prevents the display of rounding errors for
common values like days < 32.

Yea, backing out. I thought I tested it, but I guess not.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Michael Fuhr wrote:

I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=shark&amp;dt=2005-05-26%2004:21:00

I'm getting the same regression failures shown in that link; here's
an example:

OK, I have a new patch, which simplifies the code by using
TrimTrailingZeros(), gives more consistent subsecond display, and
subpresses the rounding problem:

test=> select '2005 years 4 mons 20 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-------------------------------------------
-2005 years -4 mons -20 days -15:57:12.10
(1 row)

test=> select '2005 years 4 mons 20 days 15 hours 57 mins 12.13 secs ago'::interval;
interval
-------------------------------------------
-2005 years -4 mons -20 days -15:57:12.13
(1 row)

test=> select '2005 years 4 mons 20 days 15 hours 57 mins 12.134 secs ago'::interval;
interval
--------------------------------------------
-2005 years -4 mons -20 days -15:57:12.134
(1 row)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, I have a new patch, which simplifies the code by using
TrimTrailingZeros(), gives more consistent subsecond display, and
subpresses the rounding problem:

Does anyone have any idea why the existing code is designed to keep the
number of displayed fractional digits even? It seems a bit silly to
me too, but we probably ought not remove what was clearly an intentional
behavior without understanding why it was intentional.

Also, I will point out once more that the problem is not "we only have
nine digits of precision not ten". The problem is that the precision
degrades as the interval gets larger.

regression=# select '20 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-------------------------------
-20 days -15:57:12.1000000001
(1 row)

regression=# select '100020 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-----------------------------------
-100020 days -15:57:12.1000003815
(1 row)

regression=# select '100000020 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-------------------------------------
-100000020 days -15:57:12.099609375
(1 row)

regression=#

Without accounting for that fundamental fact, you will not have a
solution, only a kluge.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, I have a new patch, which simplifies the code by using
TrimTrailingZeros(), gives more consistent subsecond display, and
subpresses the rounding problem:

Does anyone have any idea why the existing code is designed to keep the
number of displayed fractional digits even? It seems a bit silly to
me too, but we probably ought not remove what was clearly an intentional
behavior without understanding why it was intentional.

If you look at TrimTrailingZeros(), you will see it keeps at least two
decimal digits of display, so I suppose the special case while() loop
was just an older version of that. I can't imagine why they would only
want even digits, but given the other weird things in the datetime code,
it isn't surprising.

Also, I will point out once more that the problem is not "we only have
nine digits of precision not ten". The problem is that the precision
degrades as the interval gets larger.

regression=# select '20 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-------------------------------
-20 days -15:57:12.1000000001
(1 row)

regression=# select '100020 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-----------------------------------
-100020 days -15:57:12.1000003815
(1 row)

regression=# select '100000020 days 15 hours 57 mins 12.1 secs ago'::interval;
interval
-------------------------------------
-100000020 days -15:57:12.099609375
(1 row)

regression=#

Without accounting for that fundamental fact, you will not have a
solution, only a kluge.

Yep, it just hits the most common complaint for <30 days --- larger
values are going to round funny. I can't think of how to round it
cleanly without adding a lot of hacky code dealing with floats and
exponents.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073