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