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
[ bugs list removed, hackers added.]
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
Bruce Momjian pgman@candle.pha.pa.us 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
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
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
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
Kevin
