Re: timestamp not consistent with documentation or standard

Dave Martin <xxiii(at)cyberdude(dot)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