Re: BUG #2996: to_char( timestamp, 'DD-Mon-YYYY HH24:MI:SS.MS' ) reports .1000 ms
От | Tom Lane |
---|---|
Тема | Re: BUG #2996: to_char( timestamp, 'DD-Mon-YYYY HH24:MI:SS.MS' ) reports .1000 ms |
Дата | |
Msg-id | 19218.1171439650@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #2996: to_char( timestamp, 'DD-Mon-YYYY HH24:MI:SS.MS' ) reports .1000 ms ("Anthony Taylor" <tony@tg-embedded.com>) |
Список | pgsql-bugs |
"Anthony Taylor" <tony@tg-embedded.com> writes: > When using the "to_char" function to output timestamps, some timestamps > report .1000 milliseconds. Confirmed here: using your test case, successive timestamps look like 14-Feb-2007 02:44:04.998 14-Feb-2007 02:44:04.998 14-Feb-2007 02:44:04.998 14-Feb-2007 02:44:04.998 14-Feb-2007 02:44:04.999 14-Feb-2007 02:44:04.999 14-Feb-2007 02:44:04.999 14-Feb-2007 02:44:04.999 14-Feb-2007 02:44:04.999 14-Feb-2007 02:44:04.999 14-Feb-2007 02:44:04.1000 14-Feb-2007 02:44:04.1000 14-Feb-2007 02:44:04.1000 14-Feb-2007 02:44:05.000 14-Feb-2007 02:44:05.000 14-Feb-2007 02:44:05.000 14-Feb-2007 02:44:05.001 14-Feb-2007 02:44:05.001 14-Feb-2007 02:44:05.001 14-Feb-2007 02:44:05.001 14-Feb-2007 02:44:05.001 Not having looked at the code, my bet is that this occurs only without --enable-integer-timestamps; is your installation compiled with that? It would be interesting to check what happens at an hour or day boundary; I suspect the roundoff problem may extend to higher units. We've seen related bugs before :-( regards, tom lane
В списке pgsql-bugs по дате отправления: