leonbloy@sinectis.com.ar writes:
> test6=# select '01-10-2000'::date::timestamp;
> ?column?
> ------------------------------
> Sat 30 Sep 23:00:00 2000 ART
> (1 row)
> test6=# select '13-10-2000'::date::timestamp;
> ?column?
> -------------------------------
> Fri 13 Oct 00:00:00 2000 ARST
> (1 row)
> test6=# select '01-10-2000'::date::timestamp;
> ?column?
> ------------------------------
> Sat 30 Sep 00:00:00 2000 ART
> (1 row)
> The first result (30 sept 23:00:00) is obviously due to
> a timezone-daylight saving issue.
> But why postgresql throws a different result afterwards,
> is more than I can explain.
I'll bet there is some bit of internal state somewhere that affects
the results. It could be inside libc, or it could be in Postgres.
I seem to recall that we have some timezone info that gets computed
on the first call of a timezone-related operation and then saved
thereafter; maybe that's related somehow. libc probably also saves
timezone information across calls. If you alter the order of the
inquiries, how do the results change?
Thomas Lockhart is our lead guy on date/time operations, and it's
clearly time to get him involved. Thomas, have you noticed this
thread? Any luck reproducing the problem?
regards, tom lane