Re: [INTERFACES] Time and microseconds?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
Cc: "Collin F(dot) Lynch" <clynch(at)water2(dot)cs(dot)umass(dot)edu>, pgsql-interfaces(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] Time and microseconds?
Date: 1999-07-04 14:18:30
Message-ID: 17951.931097910@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il> writes:
> The TIME datatype is supposed to be compatible with SQL92, but it's, well,
> not exactly. Anyway, the default precision for time is 0, that is, no
> fractions of seconds unless stated so explicitly. However, since it stores
> milliseconds, it defies that definition.

Actually, datetime uses a float8 to store seconds-since-some-epoch-
or-other (from a quick look at the sources, it looks like datetime 0
is midnight GMT 1/1/2000). That means the precision varies depending
on how far away from time zero you are talking about. Currently,
with less than 16 million seconds left until the epoch, a standard
IEEE float8 will have about 28 bits to spare to the right of the
binary point, giving us nominal precision not much worse than
nanoseconds. For a more reasonable time range, say up to 100 years
from the epoch, you could expect microsecond precision.

The default output routine for type datetime doesn't seem to want
to print more than 2 digits after the decimal point, but you can extract
the full fractional precision with datetime_part("second", ...).

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-07-04 14:20:02 Re: [HACKERS] Tuple length limit
Previous Message Tom Lane 1999-07-04 13:55:44 Re: [HACKERS] Tuple length limit

Browse pgsql-interfaces by date

  From Date Subject
Next Message Gary Lazarus 1999-07-05 02:48:35 wild card functions in select statement?
Previous Message abdelkrim 1999-07-04 11:58:27 union and modification