Re: Unhappiness with forced precision conversion

Поиск
Список
Период
Сортировка
От F Harvell
Тема Re: Unhappiness with forced precision conversion
Дата
Msg-id 200110052145.f95Lj1B29395@odin.fts.net
обсуждение исходный текст
Ответ на Re: Unhappiness with forced precision conversion for timestamp  (Thomas Lockhart <lockhart@fourpalms.org>)
Список 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 по дате отправления:

Предыдущее
От: Patrice Hédé
Дата:
Сообщение: iso-8859-15/16 to MULE
Следующее
От: forth@pagic.net
Дата:
Сообщение: How to add a new encoding support?