On 10/13/05, Josh Berkus 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, eg, '12:13
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 i
Bruce Momjian 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 during a major r
Bruce Momjian 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
* it's consistent
Tom Lane wrote:
> Bruce Momjian 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 va
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
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
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) fiel
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 handl
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 o
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 t
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 T
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
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 da
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
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 th
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 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
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 on
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
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 pos
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 allow
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.
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:00:0
24 matches
Mail list logo
