Re: Unhappiness with forced precision conversion

From: F Harvell <fharvell(at)icgate(dot)net>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: F Harvell <fharvell(at)icgate(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unhappiness with forced precision conversion
Date: 2001-10-05 21:45:01
Message-ID: 200110052145.f95Lj1B29395@odin.fts.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message John Summerfield 2001-10-05 23:48:43 Re: cvs problem
Previous Message Peter Eisentraut 2001-10-05 21:14:22 Re: Darwin 1.4 (OS X 10.1) Broken Compile, Snapshot and