Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2] (may be
	forged)) by hub.org (8.9.3/8.9.3) with ESMTP id KAA12987;
	Sun, 4 Jul 1999 10:20:50 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA17953;
	Sun, 4 Jul 1999 10:18:30 -0400 (EDT)
To: Herouth Maoz <herouth@oumail.openu.ac.il>
cc: "Collin F. Lynch" <clynch@water2.cs.umass.edu>,
	pgsql-interfaces@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] Time and microseconds? 
In-reply-to: Your message of Sun, 4 Jul 1999 13:10:17 +0300
	<l03130301b3a4db9b4387@[147.233.159.109]>
Date: Sun, 04 Jul 1999 10:18:30 -0400
Message-ID: <17951.931097910@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Herouth Maoz <herouth@oumail.openu.ac.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