| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Glaesemann <grzm(at)myrealbox(dot)com> |
| Cc: | Achilleus Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>, "Pedro B(dot)" <pedro(dot)borracha(at)netcabo(dot)pt>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: Datetime |
| Date: | 2004-08-03 15:13:29 |
| Message-ID: | 23178.1091546009@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> No. I'm just saying that PostgreSQL does not represent or store
> timestamps as epoch timestamps internally.
You're wrong.
It's not exactly Unix-like because we use a different epoch date
(2000-1-1 not 1970-1-1) but the concept is just the same: what's
stored is the number of seconds before or after the epoch. The
default is to store this as a double precision number (hence supporting
fractional seconds, with a machine-dependent amount of precision)
but you can compile the server to use 64-bit integers instead. In that
case the integer value actually represents microseconds before or after
the epoch, and so the precision is fixed at microseconds.
What you see when you display the value is an external textual
representation, not the internal form. This is generally true for
all Postgres datatypes except text/varchar/char ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Glaesemann | 2004-08-03 22:16:16 | Re: Datetime |
| Previous Message | Michael Glaesemann | 2004-08-03 13:26:14 | Re: Datetime |