We use timestamps and intervals quite a bit in our applications. We
also use several different databases. Unfortunately, the time/date/
interval area is one that is not at all consistent between databases.
It makes life particularly difficult when trying to re-use application
code.
So far, as
On Fri, 05 Oct 2001 19:35:48 -, Thomas Lockhart wrote:
...
Have you actually used ANSI SQL9x time zones? istm that one offset fits
all is really ineffective in supporting real applications, but I'd like
to hear about how other folks use it.
Fortunately, most of our date/time
So far, as compared to many other databases, PostgreSQL, remains
pretty close to the standard (at least for our projects). The only
areas that we have had issues with is the default inclusion of the
timezone information when retriving the timestamp information and the
slightly non-standard
Tom Lane writes:
regression=# select '2001-10-04 13:52:42.845985-04'::timestamp;
timestamptz
2001-10-04 13:52:43-04
(1 row)
Throwing away the clearly stated precision of the literal doesn't
seem like the right behavior to me.
That depends on the exact
The code asserts that SQL99 requires the default precision to be zero,
but I do not agree with that reading. What I find is in 6.1:
30) If time precision is not specified, then 0 (zero) is implicit.
If timestamp precision is not specified, then 6 is implicit.
so at the
It seems to me that when there is no explicit precision notation
attached, a time/timestamp datatype should not force a precision of
zero, but should accept whatever it's given. This is analogous to
the way we do char, varchar, and numeric: there's no length limit
if you don't specify one. For
