Re: timestamps, formatting, and internals

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

In response to

Responses

Browse pgsql-general by date

  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