Re: postgresql 7.3.2 bug on date '1901-12-13' and '1901-12

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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"