I set my time zone to GMT+8 today (because the "official" timezone prescribed
by the FreeBSD timezone database for my location is "CST", which was causing
all sorts of other problems elsewhere).
Tonight, when I did my nightly data transfer (consisting of "copy to" a
bunch of tables and concatenating them together into a "pg_dump" type of
script file, copying the file over, and then loading with psql), the
backend was very unhappy.
Every "copy from" block that contained a date crashed. This was particularly
unpleasant, because the script is bracketed within a single transaction block,
and each table is emptied ("delete from") before new data is copied in. As
a result of the crashes, the transaction aborted, but psql kept on processing
away, emptying tables, crashing, and repeat.
This was on a soon-to-be production e-commerce server.
I was able to recover in a few minutes by manually editing the script file
to replace all "GMT+8" with "+0800". Had this happened during an automated
transfer on a live system, however, the problem could have been severe.
I assume that my backups are similarly corrupted.
I looked through dt.c, and ParseDateTime appears to assume that timezones
are either strictly alphabetic or of the form "+0000". EncodeDateTime,
on the other hand, blindly spits out whatever the operating system gives it
from localtime().
It seems to me there are two separate problems: 1. x == datetime_in(datetime_out(x)) should always be true for all
validx. 2. psql should exit with an error status if it receives a fatal error from the backend and isatty(0) is
false.
-Michael Robinson