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 in
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 c
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 ex
> 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-stand
> 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 is not specified, then 0 (zero) is implicit.
> If is not specified, then 6 is implicit.
> so at the very least you'd need two diff
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 e
