From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | aarni(at)kymi(dot)com |
Cc: | operationsengineer1(at)yahoo(dot)com, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Handling Time |
Date: | 2005-04-01 15:11:29 |
Message-ID: | 6462.1112368289@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Aarni =?iso-8859-1?q?Ruuhim=E4ki?= <aarni(at)kymi(dot)com> writes:
> So, the answer is that TIMESTAMP WITH TIMEZONE is good through 2037, and
> TIMESTAMP WITHOUT TIME ZONE is good through 10,000AD?
That was a reasonable answer at the time of the message you quote, but
PG 8.0 no longer relies on the OS for timezone support. So now, to
repeat the example:
regression=# select '1999-09-27'::timestamp with time zone;
timestamptz
------------------------
1999-09-27 00:00:00-04
(1 row)
regression=# select '2999-09-27'::timestamp with time zone;
timestamptz
------------------------
2999-09-27 00:00:00-05
(1 row)
or for that matter
regression=# select '0099-09-27 BC'::timestamp with time zone;
timestamptz
---------------------------
0099-09-27 00:00:00-05 BC
(1 row)
The points I made before about the dubiousness of this calculation are
as valid as ever, but it's no longer a matter of not being able to do
it, it's just a matter of how much space you want to expend in the
timezone data files. (The first and last dates shown above are outside
the range of the Americas/New_York timezone file that we supply, so PG
falls back to assuming local standard time.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-01 15:37:29 | Re: VACUUM and other maintenance work |
Previous Message | Christian Hofmann | 2005-04-01 13:03:43 | VACUUM and other maintenance work |