If you are going to roll this back in 8.1 to reevaluate the issue, I
think the ANSI/ISO standards should be reviewed as part of that
reevaluation. The standard seems rich enough in this area to
address all of the concerns I've seen expressed on this thread.
All the usual advantages for standards c
I'm not seeing it. It seems to me that timestamps can be defined
WITH or WITHOUT time zone, and the semantics of calculating an
interval are fairly clear in either case. An interval doesn't seem
like it should have an associated time zone. Adding an interval
to a timestamp would use the time zon
I hate to answer my own question, but I think I may have spotted
the issue. I forgot that a TIMESTAMP WITH TIME ZONE is
actually stored without a time zone. This datatype would need
to better comply with the ANSI/ISO standard for the ANSI/ISO
operations on them to work properly.
-Kevin
>>> "Ke
Sorry, I should have CC'ed hackers on this. The issue is that because
of interval_justify_hours(), subtracting a fixed interval from a
timestamp and re-adding the same value produces a different result.
---
Bruce Momjian wr
[ bugs list removed, hackers added.]
Tom Lane wrote:
> Bruce Momjian writes:
> > I saw a lot of disussion because I forgot to specify that my tests were
> > for EST5EDT, but what about the use of interval_justify_hours() in
> > timestamp_mi(). Is this something we want to change?
>
> It's too
Bruce Momjian writes:
> Keep in mind that the addition of the interval_justify_hours() did
> generate some regression test changes, so removing
> interval_justify_hours() might just take the results back to what we had
> in 8.0.
Not hardly. I tried already. The existing timestamp_mi behavior is
Tom Lane wrote:
> Bruce Momjian writes:
> > Keep in mind that the addition of the interval_justify_hours() did
> > generate some regression test changes, so removing
> > interval_justify_hours() might just take the results back to what we had
> > in 8.0.
>
> Not hardly. I tried already. The exi
Bruce Momjian writes:
> Tom Lane wrote:
>> Not hardly. I tried already. The existing timestamp_mi behavior is
>> probably as close to 8.0 as we can get given the change in underlying
>> representation.
> You mean the '6432 hours' is a worse change, OK.
Well, it's sure not a small change, and w
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> The standard seems rich enough in this area to
> address all of the concerns I've seen expressed on this thread.
> All the usual advantages for standards compliance accrue, as well.
Last I checked, the standard completely failed to deal with daylight