Re: Unhappiness with forced precision conversion - Mailing list pgsql-hackers

From F Harvell
Subject Re: Unhappiness with forced precision conversion
Date
Msg-id 200110052145.f95Lj1B29395@odin.fts.net
Whole thread Raw
In response to Re: Unhappiness with forced precision conversion for timestamp  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-hackers
On Fri, 05 Oct 2001 19:35:48 -0000, 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 information is self-referential.
I.e., we are usually looking at intervals between an initial date/
timestamp and the current date/timestamp.  This has effectively
eliminated the need to deal with time zones.

> > In this case, I believe that it would be preferable to stick with the
> > TIME(0) and TIMESTAMP(6) default precision.  In our applications, we
> > always specify the precision, so, the default precision is not a real
> > concern for us, however, for portability, I still suggest sticking
> > with the standard.
> 
> We are likely to use the 0/6 convention for the next release (though why
> TIME should default to zero decimal places and TIMESTAMP default to
> something else makes no sense).
 The only thing that I can think of is that originally, the DATE and
TIME types were integer values and that when the "new" TIMESTAMP data
type was "created" the interest was to increase the precision.  I
would guess, as you have also suggested, that the standards were based
upon existing implementations (along with an interest in backwards
compatibility).

Thanks,
F Harvell




pgsql-hackers by date:

Previous
From: Patrice Hédé
Date:
Subject: iso-8859-15/16 to MULE
Next
From: forth@pagic.net
Date:
Subject: How to add a new encoding support?