On 10/13/05, Josh Berkus josh@agliodbs.com wrote:
Tom,
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes. This for two reasons:
* existing dump files may contain such values
* it's consistent with allowing,
Where are we on this? I see current CVS behaving the same as below,
except the last query now returns 24:00:00.
---
Tom Lane wrote:
Inserting into a time field with limited precision rounds off, which
is good except for
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Where are we on this?
We haven't decided what to do.
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes. This for two reasons:
* existing dump files may
Bruce Momjian pgman@candle.pha.pa.us writes:
Where are we on this?
We haven't decided what to do.
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes. This for two reasons:
* existing dump files may contain such values
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes.
Is this a must-fix for 8.1?
No, since it's a pre-existing issue, but it's the kind of thing that
should be changed
Tom,
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes. This for two reasons:
* existing dump files may contain such values
* it's consistent with allowing, eg, '12:13:60', which we
allow even though it's
On Mon, Sep 26, 2005 at 06:23:06PM +0200, Andreas Pflug wrote:
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from
On Mon, Sep 26, 2005 at 11:46:47AM -0400, Tom Lane wrote:
Jochem van Dieten [EMAIL PROTECTED] writes:
On 9/26/05, Dennis Bjorklund wrote:
One reason is because it's what the standard demand.
Could you cite that? The only thing I can find in the SQL standard is
that the hour field in an
On Sun, 25 Sep 2005, Tom Lane wrote:
Alternatively: why are we forbidding the value 24:00:00 anyway? Is
there a reason not to allow the hours field to exceed 23?
One reason is because it's what the standard demand. Another is that it
isn't a proper time, just like feb 31 isn't a proper date.
Actually, I think there is a case where 24:00 is a proper time. Isn't
it used for adding leap seconds ?
Dave
On 26-Sep-05, at 3:39 AM, Dennis Bjorklund wrote:
On Sun, 25 Sep 2005, Tom Lane wrote:
Alternatively: why are we forbidding the value 24:00:00 anyway? Is
there a reason not to
Dave Cramer [EMAIL PROTECTED] writes:
Actually, I think there is a case where 24:00 is a proper time. Isn't
it used for adding leap seconds ?
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
I suppose there's another
On Mon, 26 Sep 2005, Tom Lane wrote:
Actually, I think there is a case where 24:00 is a proper time. Isn't
it used for adding leap seconds ?
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
Yes, and it can go up to
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
Yes, and it can go up to 23:59:60.99 (depending on how many fractional
seconds one want).
On Mon, 26 Sep 2005, Tom Lane wrote:
Yes, and it can go up to 23:59:60.99 (depending on how many fractional
seconds one want).
That's an urban legend. There never have been, and never will be, two
leap seconds instituted in the same minute. We really should reject
anything larger
Tom Lane [EMAIL PROTECTED] writes:
That's an urban legend. There never have been, and never will be, two
leap seconds instituted in the same minute. We really should reject
anything larger than '23:59:60'.
I don't understand. The last second of a normal minute goes from 59.0 to
59.999
On 9/26/05, Dennis Bjorklund wrote:
On Sun, 25 Sep 2005, Tom Lane wrote:
Alternatively: why are we forbidding the value 24:00:00 anyway? Is
there a reason not to allow the hours field to exceed 23?
One reason is because it's what the standard demand.
Could you cite that? The only thing I
Jochem van Dieten [EMAIL PROTECTED] writes:
On 9/26/05, Dennis Bjorklund wrote:
One reason is because it's what the standard demand.
Could you cite that? The only thing I can find in the SQL standard is
that the hour field in an INTERVAL can not exceed 23, not datetimes.
SQL99 has
Dennis Bjorklund [EMAIL PROTECTED] writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If TD is the datetime data
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
Yes, and it can go up to 23:59:60.99 (depending on how many fractional
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If TD
On Mon, 26 Sep 2005, Tom Lane wrote:
b) If SD is TIME WITHOUT TIME ZONE, then TV is SV, with
implementation-defined rounding or truncation if necessary.
So it's implementation-defined what we do.
Truncation would avoid the problem but of course loses some of the
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
b) If SD is TIME WITHOUT TIME ZONE, then TV is SV, with
implementation-defined rounding or truncation if necessary.
So it's implementation-defined what we do.
IMHO Since 23:59:59.99 probably means the last milliseconds of this
day,
Tom Lane wrote:
Hm, so the proposal is round unless that would produce 24:00:00, in
which case truncate? Seems a bit ugly but it would follow the letter
of the spec, and avoid rejecting inputs that we used to accept. It's
still not very clear what to do with '23:59:60.9' though.
I'd handle
Inserting into a time field with limited precision rounds off, which
is good except for this case:
regression=# select '23:59:59.9'::time(0);
time
--
24:00:00
(1 row)
This is bad because:
regression=# select '24:00:00'::time(0);
ERROR: date/time field value out of range:
24 matches
Mail list logo
