From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Eric Lemes" <eric(dot)lemes(at)zanthus(dot)com(dot)br> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: RES: Datetime problem |
Date: | 2004-06-14 18:47:15 |
Message-ID: | 5210.1087238835@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Eric Lemes" <eric(dot)lemes(at)zanthus(dot)com(dot)br> writes:
> - PostgreSQL 7.3.2 on i386-redhat-linux GCC 3.2.2
> - Timezone: Brazil (GMT-3, I think).
Ah, and 2004-10-10 is a daylight savings transition day where you live,
right? (Or at least the obsolete timezone file you have thinks so...)
So local midnight on that day doesn't really exist: you go from 11:59:59
standard time to 01:00:00 summer time.
PG 7.3 and before got this boundary condition wrong in some cases, but
I think 7.4 gets it right. The rule we use now is to interpret invalid
or ambiguous times as local standard time (hence, this input means
midnight standard time), which is what to_timestamp is doing. However,
on reverse conversion you'll get the normalized form of the time, which
is 01:00:00 summer time.
I think what is happening in 7.3 is that the input is interpreted as
midnight summer time, which would reverse-convert as 11:00 PM standard
time...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-06-14 18:51:49 | Re: a query with = ALL |
Previous Message | Stephan Szabo | 2004-06-14 18:26:55 | Re: query with =ALL |