Re: timestamp not consistent with documentation or standard
От | Tom Lane |
---|---|
Тема | Re: timestamp not consistent with documentation or standard |
Дата | |
Msg-id | 26109.994723662@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | timestamp not consistent with documentation or standard (Dave Martin <xxiii@cyberdude.com>) |
Список | 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 по дате отправления: