mirror of
https://github.com/postgres/postgres.git
synced 2025-05-28 05:21:27 +03:00
b2c64f571d
It's intentional that we don't allow values greater than 24 hours, while we do allow "24:00:00" as well as "23:59:60" as inputs. However, the range check was miscoded in such a way that it would accept "23:59:60.nnn" with a nonzero fraction. For time or timetz, the stored result would then be greater than "24:00:00" which would fail dump/reload, not to mention possibly confusing other operations. Fix by explicitly calculating the result and making sure it does not exceed 24 hours. (This calculation is redundant with what will happen later in tm2time or tm2timetz. Maybe someday somebody will find that annoying enough to justify refactoring to avoid the duplication; but that seems too invasive for a back-patched bug fix, and the cost is probably unmeasurable anyway.) Note that this change also rejects such input as the time portion of a timestamp(tz) value. Back-patch to v10. The bug is far older, but to change this pre-v10 we'd need to ensure that the logic behaves sanely with float timestamps, which is possibly nontrivial due to roundoff considerations. Doesn't really seem worth troubling with. Per report from Christoph Berg. Discussion: https://postgr.es/m/20200520125807.GB296739@msg.df7cb.de
58 lines
2.0 KiB
SQL
58 lines
2.0 KiB
SQL
--
|
|
-- TIMETZ
|
|
--
|
|
|
|
CREATE TABLE TIMETZ_TBL (f1 time(2) with time zone);
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('00:01 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('01:00 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('02:03 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('07:07 PST');
|
|
INSERT INTO TIMETZ_TBL VALUES ('08:08 EDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('11:59 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('12:00 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('12:01 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('23:59 PDT');
|
|
INSERT INTO TIMETZ_TBL VALUES ('11:59:59.99 PM PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('2003-03-07 15:36:39 America/New_York');
|
|
INSERT INTO TIMETZ_TBL VALUES ('2003-07-07 15:36:39 America/New_York');
|
|
-- this should fail (the timezone offset is not known)
|
|
INSERT INTO TIMETZ_TBL VALUES ('15:36:39 America/New_York');
|
|
-- this should fail (timezone not specified without a date)
|
|
INSERT INTO TIMETZ_TBL VALUES ('15:36:39 m2');
|
|
-- this should fail (dynamic timezone abbreviation without a date)
|
|
INSERT INTO TIMETZ_TBL VALUES ('15:36:39 MSK m2');
|
|
|
|
|
|
SELECT f1 AS "Time TZ" FROM TIMETZ_TBL;
|
|
|
|
SELECT f1 AS "Three" FROM TIMETZ_TBL WHERE f1 < '05:06:07-07';
|
|
|
|
SELECT f1 AS "Seven" FROM TIMETZ_TBL WHERE f1 > '05:06:07-07';
|
|
|
|
SELECT f1 AS "None" FROM TIMETZ_TBL WHERE f1 < '00:00-07';
|
|
|
|
SELECT f1 AS "Ten" FROM TIMETZ_TBL WHERE f1 >= '00:00-07';
|
|
|
|
-- Check edge cases
|
|
SELECT '23:59:59.999999'::timetz;
|
|
SELECT '23:59:59.9999999'::timetz; -- rounds up
|
|
SELECT '23:59:60'::timetz; -- rounds up
|
|
SELECT '24:00:00'::timetz; -- allowed
|
|
SELECT '24:00:00.01'::timetz; -- not allowed
|
|
SELECT '23:59:60.01'::timetz; -- not allowed
|
|
SELECT '24:01:00'::timetz; -- not allowed
|
|
SELECT '25:00:00'::timetz; -- not allowed
|
|
|
|
--
|
|
-- TIME simple math
|
|
--
|
|
-- We now make a distinction between time and intervals,
|
|
-- and adding two times together makes no sense at all.
|
|
-- Leave in one query to show that it is rejected,
|
|
-- and do the rest of the testing in horology.sql
|
|
-- where we do mixed-type arithmetic. - thomas 2000-12-02
|
|
|
|
SELECT f1 + time with time zone '00:01' AS "Illegal" FROM TIMETZ_TBL;
|