From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | Arnold Mavromatis <A(dot)Mavromatis(at)bom(dot)gov(dot)au>, pgsql-bugs(at)postgresql(dot)org, Lan Tran <L(dot)Tran(at)bom(dot)gov(dot)au>, "'meg(at)bom(dot)gov(dot)au'" <meg(at)bom(dot)gov(dot)au>, "'aam(at)bom(dot)gov(dot)au'" <aam(at)bom(dot)gov(dot)au> |
Subject: | Re: postgresql 7.3.2 bug on date '1901-12-13' and '1901-12 |
Date: | 2003-08-21 14:23:32 |
Message-ID: | 6802.1061475812@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> Hmm, I just got my machine to give a similar failure mode with
> a slightly wacky input.
Perhaps more to the point:
regression=# select timestamptz '1901/12/13 0:0:0';
timestamptz
---------------------
1901-12-13 00:00:00
(1 row)
regression=# select timestamptz '1901/12/14 0:0:0';
timestamptz
------------------------
1901-12-14 00:00:00-05
(1 row)
Note the lack of timezone in the first output.
It looks like 1901/12/14 is the oldest date for which the system will
return timezone information; IIRC, this is the oldest date representable
as a 32-bit time_t. PG implicitly assumes that timestamps before that
are always GMT.
This still doesn't explain why Arnold sees a failure with to_date and
we don't, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-21 14:49:10 | Re: 1.0 in function call not regarded as REAL in 7.3.2 |
Previous Message | Boris Folgmann | 2003-08-21 14:04:38 | 1.0 in function call not regarded as REAL in 7.3.2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2003-08-21 14:59:21 | Re: Buglist |
Previous Message | Shridhar Daithankar | 2003-08-21 14:18:29 | Re: [pgsql-advocacy] Need concrete "Why Postgres not MySQL" |