Re: timestamp not consistent with documentation or standard - Mailing list pgsql-hackers

From Tom Lane
Subject Re: timestamp not consistent with documentation or standard
Date
Msg-id 26109.994723662@sss.pgh.pa.us
Whole thread Raw
In response to timestamp not consistent with documentation or standard  (Dave Martin <xxiii@cyberdude.com>)
List pgsql-hackers
Dave Martin <xxiii@cyberdude.com> writes:
> Ok, i've been told to bring this up on this mailing list, so, I do so:
> rather than kill myself re-explaining, i'll just cut&paste my email
> correspondence.

Actually, what you should have done was consult the archives of this
list.  You will find that you have wandered into the no man's land
of an armed conflict :-(.  Unless you have some new argument that will
persuade one camp or the other to concede, it's unlikely that the
naming of the timestamp type (there is only one, and no visible interest
in implementing more) will change soon.


>> However its output incorrectly, when years exceed 10000.
>> 
>> insert into test values('05-05-12080', '05-05-12080 1:1:1-7:00');
>> insert into test values('05-05-12080', '05-05-12080 1:1:1+7:00');
>> 
>> select * from test;
>> w          |          o
>> ---------------------+---------------------
>> 2080-05-05 00:00:00 | 2080-05-05 00:00:00
>> 2080-05-05 00:00:00 | 2080-05-05 08:01:01
>> 12080-05-05 00:0000 | 12080-05-05 08:0101
>> 12080-05-05 00:0000 | 12080-05-04 18:0101

This is definitely a bug --- looks like EncodeDateTime fails to consider
the possibility that the output of sprintf will be longer than "normal".
Will fix.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dave Martin
Date:
Subject: timestamp not consistent with documentation or standard
Next
From: "Christopher Kings-Lynne"
Date:
Subject: More ADD CONSTRAINT behaviour questions