Re: [BUGS] BUG #1993: Adding/subtracting negative
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 compliance accrue, as well.
So, for example, you could specify:
-- to get the interval in days, hours, and minutes:
(timestampx - timestampy) day to minute
-- to get the interval in days, to 2 decimal places:
(timestampx - timestampy) day{2)
-- to get the interval in hours:
(timestampx - timestampy) hour
Bruce Momjian <pgman@candle.pha.pa.us> >>>
I guess my point is that we are changing 8.0.X behavior so we better be
sure it is now the way we want it to remain.
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> 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
savings time changes, making it pretty useless as a guide to solving
the problems we want to deal with.
regards, tom lane
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 zone of the timestamp.
What am I missing?
-Kevin
Tom Lane <tgl@sss.pgh.pa.us> >>>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> 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
savings time changes, making it pretty useless as a guide to solving
the problems we want to deal with.
regards, tom lane
Import Notes
Resolved by subject fallback
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 Grittner" <Kevin.Grittner@wicourts.gov> >>>
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 zone of the timestamp.
What am I missing?
-Kevin
Tom Lane <tgl@sss.pgh.pa.us> >>>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> 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
savings time changes, making it pretty useless as a guide to solving
the problems we want to deal with.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Import Notes
Resolved by subject fallback