Re: BUG #4789: ERROR 22008 on timestamp import - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4789: ERROR 22008 on timestamp import
Date
Msg-id 16209.1241201543@sss.pgh.pa.us
Whole thread Raw
In response to BUG #4789: ERROR 22008 on timestamp import  ("Robert Kruuus" <robert.kruus@gov.sk.ca>)
Responses Re: BUG #4789: ERROR 22008 on timestamp import
List pgsql-bugs
"Kruus, Robert ENV" <Robert.Kruus@gov.sk.ca> writes:
>> Hmph.  Is your installation built with --enable-integer-datetimes?

> Yes it is 'on'.

On further probing, I can make it happen with float datetimes too,
if I throw enough fractional nines in there:

regression=# select '1999-08-06 00:12:57.999999999999999999999999999900'::timestamptz;
ERROR:  date/time field value out of range: "1999-08-06 00:12:57.999999999999999999999999999900"

The problem seems to be here:

    /* do a sanity check */
#ifdef HAVE_INT64_TIMESTAMP
    if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_min > 59 ||
        tm->tm_sec < 0 || tm->tm_sec > 60 || *fsec < INT64CONST(0) ||
        *fsec >= USECS_PER_SEC)
        return DTERR_FIELD_OVERFLOW;
#else
    if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_min > 59 ||
        tm->tm_sec < 0 || tm->tm_sec > 60 || *fsec < 0 || *fsec >= 1)
        return DTERR_FIELD_OVERFLOW;
#endif

With enough nines, the fsec value is going to round up to 1.0 (float
case) or USECS_PER_SEC (int case).  So I think that this check ought
to allow, not exclude, the boundary value.  And then we need to be
sure the subsequent code adds the values together properly, but that
probably happens okay already.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: BUG #4789: ERROR 22008 on timestamp import
Next
From: Tom Lane
Date:
Subject: Re: BUG #4789: ERROR 22008 on timestamp import