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
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
