| 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: | Whole Thread | Raw Message | 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" |