| From: | David Salisbury <salisbury(at)globe(dot)gov> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
| Cc: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: timestamps, formatting, and internals |
| Date: | 2012-05-30 20:48:35 |
| Message-ID: | 4FC687A3.8060304@globe.gov |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 5/30/12 9:42 AM, Adrian Klaver wrote:
> Think I realize where the confusion is now. When Jasen mentioned integer
> datetimes he was referring to the internal storage format Postgres uses
> to record the datetime value. Via the magic of programming(others will
> have to fill that part in) the internal format can represent time down
> to microseconds even though the value is actually stored as an
> eight-byte integer. When you do an explicit cast of a timestamp value to
> integer you are asking that the value be only a whole number and the
> decimal portion is discarded. In other words the internal integer
> encodes the decimal values the external integer does not.
Thanks! I was looking for some sort of verification along these lines.
So in my mind, the internal storage of a timestamp would be the number
of milliseconds since 1970 ( or similar ). But to me, if I cast something
that is an integer into an integer it would still be an integer ;) , and
still hold the milliseconds. Perhaps if I cast a datetime into a bigint it'll
still hold the number of ms? Some sort of parameter setting for dates
would be nice to be able to default a date/time format down to the ms, w/o
having to explicitly format it with every select... imho.
-ds
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2012-05-30 21:06:10 | Re: Picksplit warning |
| Previous Message | Tom Lane | 2012-05-30 20:47:34 | Re: Postgres no longer starts |