Regression tests fail with tzdata 2024b
Building --with-system-tzdata and the latest tzdata 2024b fails the
regression tests for me (see attached .diffs). This seems to be because
of [1]https://github.com/eggert/tz/commit/a0b09c0230089252acf2eb0f1ba922e99f7f4a03, which changed the way "PST8PDT" is handled. This is the timezone
that the regression tests are run with.
From 2024b on, "PST8PDT" is the same as "America/Los_Angeles", so by
changing the regression tests to use the latter as the default, we're
getting consistent output on at least 2024a and 2024b.
Patch attached.
Best,
Wolfgang
[1]: https://github.com/eggert/tz/commit/a0b09c0230089252acf2eb0f1ba922e99f7f4a03
https://github.com/eggert/tz/commit/a0b09c0230089252acf2eb0f1ba922e99f7f4a03
Attachments:
regression.diffstext/plain; charset=UTF-8; name=regression.diffsDownload
diff -U3 /build/source/src/test/regress/expected/date.out /build/source/build/testrun/regress/regress/results/date.out
--- /build/source/src/test/regress/expected/date.out 1970-01-01 00:00:01.000000000 +0000
+++ /build/source/build/testrun/regress/regress/results/date.out 2024-09-13 17:58:09.142429792 +0000
@@ -1295,7 +1295,7 @@
SELECT DATE_TRUNC('MILLENNIUM', DATE '1970-03-20'); -- 1001-01-01
date_trunc
------------------------------
- Thu Jan 01 00:00:00 1001 PST
+ Thu Jan 01 00:00:00 1001 LMT
(1 row)
SELECT DATE_TRUNC('CENTURY', TIMESTAMP '1970-03-20 04:30:00.00000'); -- 1901
@@ -1319,13 +1319,13 @@
SELECT DATE_TRUNC('CENTURY', DATE '0002-02-04'); -- 0001-01-01
date_trunc
------------------------------
- Mon Jan 01 00:00:00 0001 PST
+ Mon Jan 01 00:00:00 0001 LMT
(1 row)
SELECT DATE_TRUNC('CENTURY', DATE '0055-08-10 BC'); -- 0100-01-01 BC
date_trunc
---------------------------------
- Tue Jan 01 00:00:00 0100 PST BC
+ Tue Jan 01 00:00:00 0100 LMT BC
(1 row)
SELECT DATE_TRUNC('DECADE', DATE '1993-12-25'); -- 1990-01-01
@@ -1337,13 +1337,13 @@
SELECT DATE_TRUNC('DECADE', DATE '0004-12-25'); -- 0001-01-01 BC
date_trunc
---------------------------------
- Sat Jan 01 00:00:00 0001 PST BC
+ Sat Jan 01 00:00:00 0001 LMT BC
(1 row)
SELECT DATE_TRUNC('DECADE', DATE '0002-12-31 BC'); -- 0011-01-01 BC
date_trunc
---------------------------------
- Mon Jan 01 00:00:00 0011 PST BC
+ Mon Jan 01 00:00:00 0011 LMT BC
(1 row)
--
diff -U3 /build/source/src/test/regress/expected/timestamptz.out /build/source/build/testrun/regress/regress/results/timestamptz.out
--- /build/source/src/test/regress/expected/timestamptz.out 1970-01-01 00:00:01.000000000 +0000
+++ /build/source/build/testrun/regress/regress/results/timestamptz.out 2024-09-13 17:58:09.479104285 +0000
@@ -330,12 +330,12 @@
Fri Feb 14 17:32:01 1997 PST
Sat Feb 15 17:32:01 1997 PST
Sun Feb 16 17:32:01 1997 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Sun Feb 16 17:32:01 1997 PST
Sat Feb 16 17:32:01 2097 PST
@@ -359,19 +359,19 @@
SELECT '4714-11-24 00:00:00+00 BC'::timestamptz;
timestamptz
---------------------------------
- Sun Nov 23 16:00:00 4714 PST BC
+ Sun Nov 23 16:07:02 4714 LMT BC
(1 row)
SELECT '4714-11-23 16:00:00-08 BC'::timestamptz;
timestamptz
---------------------------------
- Sun Nov 23 16:00:00 4714 PST BC
+ Sun Nov 23 16:07:02 4714 LMT BC
(1 row)
SELECT 'Sun Nov 23 16:00:00 4714 PST BC'::timestamptz;
timestamptz
---------------------------------
- Sun Nov 23 16:00:00 4714 PST BC
+ Sun Nov 23 16:07:02 4714 LMT BC
(1 row)
SELECT '4714-11-23 23:59:59+00 BC'::timestamptz; -- out of range
@@ -461,12 +461,12 @@
---------------------------------
-infinity
Wed Dec 31 16:00:00 1969 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Wed Feb 28 17:32:01 1996 PST
Thu Feb 29 17:32:01 1996 PST
@@ -529,12 +529,12 @@
Fri Feb 14 17:32:01 1997 PST
Sat Feb 15 17:32:01 1997 PST
Sun Feb 16 17:32:01 1997 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Sun Feb 16 17:32:01 1997 PST
Sat Feb 16 17:32:01 2097 PST
@@ -561,12 +561,12 @@
-infinity
Wed Dec 31 16:00:00 1969 PST
Thu Jan 02 00:00:00 1997 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Wed Feb 28 17:32:01 1996 PST
Thu Feb 29 17:32:01 1996 PST
@@ -920,12 +920,12 @@
Fri Feb 14 17:32:01 1997 PST | 1997 | 2 | 14 | 17 | 32 | 1
Sat Feb 15 17:32:01 1997 PST | 1997 | 2 | 15 | 17 | 32 | 1
Sun Feb 16 17:32:01 1997 PST | 1997 | 2 | 16 | 17 | 32 | 1
- Tue Feb 16 17:32:01 0097 PST BC | -97 | 2 | 16 | 17 | 32 | 1
- Sat Feb 16 17:32:01 0097 PST | 97 | 2 | 16 | 17 | 32 | 1
- Thu Feb 16 17:32:01 0597 PST | 597 | 2 | 16 | 17 | 32 | 1
- Tue Feb 16 17:32:01 1097 PST | 1097 | 2 | 16 | 17 | 32 | 1
- Sat Feb 16 17:32:01 1697 PST | 1697 | 2 | 16 | 17 | 32 | 1
- Thu Feb 16 17:32:01 1797 PST | 1797 | 2 | 16 | 17 | 32 | 1
+ Tue Feb 16 17:32:01 0097 LMT BC | -97 | 2 | 16 | 17 | 32 | 1
+ Sat Feb 16 17:32:01 0097 LMT | 97 | 2 | 16 | 17 | 32 | 1
+ Thu Feb 16 17:32:01 0597 LMT | 597 | 2 | 16 | 17 | 32 | 1
+ Tue Feb 16 17:32:01 1097 LMT | 1097 | 2 | 16 | 17 | 32 | 1
+ Sat Feb 16 17:32:01 1697 LMT | 1697 | 2 | 16 | 17 | 32 | 1
+ Thu Feb 16 17:32:01 1797 LMT | 1797 | 2 | 16 | 17 | 32 | 1
Tue Feb 16 17:32:01 1897 PST | 1897 | 2 | 16 | 17 | 32 | 1
Sun Feb 16 17:32:01 1997 PST | 1997 | 2 | 16 | 17 | 32 | 1
Sat Feb 16 17:32:01 2097 PST | 2097 | 2 | 16 | 17 | 32 | 1
@@ -994,12 +994,12 @@
Fri Feb 14 17:32:01 1997 PST | 1 | 1000 | 1000000
Sat Feb 15 17:32:01 1997 PST | 1 | 1000 | 1000000
Sun Feb 16 17:32:01 1997 PST | 1 | 1000 | 1000000
- Tue Feb 16 17:32:01 0097 PST BC | 1 | 1000 | 1000000
- Sat Feb 16 17:32:01 0097 PST | 1 | 1000 | 1000000
- Thu Feb 16 17:32:01 0597 PST | 1 | 1000 | 1000000
- Tue Feb 16 17:32:01 1097 PST | 1 | 1000 | 1000000
- Sat Feb 16 17:32:01 1697 PST | 1 | 1000 | 1000000
- Thu Feb 16 17:32:01 1797 PST | 1 | 1000 | 1000000
+ Tue Feb 16 17:32:01 0097 LMT BC | 1 | 1000 | 1000000
+ Sat Feb 16 17:32:01 0097 LMT | 1 | 1000 | 1000000
+ Thu Feb 16 17:32:01 0597 LMT | 1 | 1000 | 1000000
+ Tue Feb 16 17:32:01 1097 LMT | 1 | 1000 | 1000000
+ Sat Feb 16 17:32:01 1697 LMT | 1 | 1000 | 1000000
+ Thu Feb 16 17:32:01 1797 LMT | 1 | 1000 | 1000000
Tue Feb 16 17:32:01 1897 PST | 1 | 1000 | 1000000
Sun Feb 16 17:32:01 1997 PST | 1 | 1000 | 1000000
Sat Feb 16 17:32:01 2097 PST | 1 | 1000 | 1000000
@@ -1069,12 +1069,12 @@
Fri Feb 14 17:32:01 1997 PST | 1997 | 7 | 5 | 5 | 45
Sat Feb 15 17:32:01 1997 PST | 1997 | 7 | 6 | 6 | 46
Sun Feb 16 17:32:01 1997 PST | 1997 | 7 | 7 | 0 | 47
- Tue Feb 16 17:32:01 0097 PST BC | -97 | 7 | 2 | 2 | 47
- Sat Feb 16 17:32:01 0097 PST | 97 | 7 | 6 | 6 | 47
- Thu Feb 16 17:32:01 0597 PST | 597 | 7 | 4 | 4 | 47
- Tue Feb 16 17:32:01 1097 PST | 1097 | 7 | 2 | 2 | 47
- Sat Feb 16 17:32:01 1697 PST | 1697 | 7 | 6 | 6 | 47
- Thu Feb 16 17:32:01 1797 PST | 1797 | 7 | 4 | 4 | 47
+ Tue Feb 16 17:32:01 0097 LMT BC | -97 | 7 | 2 | 2 | 47
+ Sat Feb 16 17:32:01 0097 LMT | 97 | 7 | 6 | 6 | 47
+ Thu Feb 16 17:32:01 0597 LMT | 597 | 7 | 4 | 4 | 47
+ Tue Feb 16 17:32:01 1097 LMT | 1097 | 7 | 2 | 2 | 47
+ Sat Feb 16 17:32:01 1697 LMT | 1697 | 7 | 6 | 6 | 47
+ Thu Feb 16 17:32:01 1797 LMT | 1797 | 7 | 4 | 4 | 47
Tue Feb 16 17:32:01 1897 PST | 1897 | 7 | 2 | 2 | 47
Sun Feb 16 17:32:01 1997 PST | 1997 | 7 | 7 | 0 | 47
Sat Feb 16 17:32:01 2097 PST | 2097 | 7 | 6 | 6 | 47
@@ -1146,12 +1146,12 @@
Fri Feb 14 17:32:01 1997 PST | 199 | 20 | 2 | 2450495 | 855970321
Sat Feb 15 17:32:01 1997 PST | 199 | 20 | 2 | 2450496 | 856056721
Sun Feb 16 17:32:01 1997 PST | 199 | 20 | 2 | 2450497 | 856143121
- Tue Feb 16 17:32:01 0097 PST BC | -10 | -1 | -1 | 1686043 | -65192682479
- Sat Feb 16 17:32:01 0097 PST | 9 | 1 | 1 | 1756537 | -59102000879
- Thu Feb 16 17:32:01 0597 PST | 59 | 6 | 1 | 1939158 | -43323546479
- Tue Feb 16 17:32:01 1097 PST | 109 | 11 | 2 | 2121779 | -27545092079
- Sat Feb 16 17:32:01 1697 PST | 169 | 17 | 2 | 2340925 | -8610877679
- Thu Feb 16 17:32:01 1797 PST | 179 | 18 | 2 | 2377449 | -5455204079
+ Tue Feb 16 17:32:01 0097 LMT BC | -10 | -1 | -1 | 1686043 | -65192682901
+ Sat Feb 16 17:32:01 0097 LMT | 9 | 1 | 1 | 1756537 | -59102001301
+ Thu Feb 16 17:32:01 0597 LMT | 59 | 6 | 1 | 1939158 | -43323546901
+ Tue Feb 16 17:32:01 1097 LMT | 109 | 11 | 2 | 2121779 | -27545092501
+ Sat Feb 16 17:32:01 1697 LMT | 169 | 17 | 2 | 2340925 | -8610878101
+ Thu Feb 16 17:32:01 1797 LMT | 179 | 18 | 2 | 2377449 | -5455204501
Tue Feb 16 17:32:01 1897 PST | 189 | 19 | 2 | 2413973 | -2299530479
Sun Feb 16 17:32:01 1997 PST | 199 | 20 | 2 | 2450497 | 856143121
Sat Feb 16 17:32:01 2097 PST | 209 | 21 | 3 | 2487022 | 4011903121
@@ -1221,12 +1221,12 @@
Fri Feb 14 17:32:01 1997 PST | -28800 | -8 | 0
Sat Feb 15 17:32:01 1997 PST | -28800 | -8 | 0
Sun Feb 16 17:32:01 1997 PST | -28800 | -8 | 0
- Tue Feb 16 17:32:01 0097 PST BC | -28800 | -8 | 0
- Sat Feb 16 17:32:01 0097 PST | -28800 | -8 | 0
- Thu Feb 16 17:32:01 0597 PST | -28800 | -8 | 0
- Tue Feb 16 17:32:01 1097 PST | -28800 | -8 | 0
- Sat Feb 16 17:32:01 1697 PST | -28800 | -8 | 0
- Thu Feb 16 17:32:01 1797 PST | -28800 | -8 | 0
+ Tue Feb 16 17:32:01 0097 LMT BC | -28378 | -7 | -52
+ Sat Feb 16 17:32:01 0097 LMT | -28378 | -7 | -52
+ Thu Feb 16 17:32:01 0597 LMT | -28378 | -7 | -52
+ Tue Feb 16 17:32:01 1097 LMT | -28378 | -7 | -52
+ Sat Feb 16 17:32:01 1697 LMT | -28378 | -7 | -52
+ Thu Feb 16 17:32:01 1797 LMT | -28378 | -7 | -52
Tue Feb 16 17:32:01 1897 PST | -28800 | -8 | 0
Sun Feb 16 17:32:01 1997 PST | -28800 | -8 | 0
Sat Feb 16 17:32:01 2097 PST | -28800 | -8 | 0
@@ -1300,12 +1300,12 @@
Fri Feb 14 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450495 | 855970321.000000
Sat Feb 15 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450496 | 856056721.000000
Sun Feb 16 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450497 | 856143121.000000
- Tue Feb 16 17:32:01 0097 PST BC | 1000000 | 1000.000 | 1.000000 | 1686043 | -65192682479.000000
- Sat Feb 16 17:32:01 0097 PST | 1000000 | 1000.000 | 1.000000 | 1756537 | -59102000879.000000
- Thu Feb 16 17:32:01 0597 PST | 1000000 | 1000.000 | 1.000000 | 1939158 | -43323546479.000000
- Tue Feb 16 17:32:01 1097 PST | 1000000 | 1000.000 | 1.000000 | 2121779 | -27545092079.000000
- Sat Feb 16 17:32:01 1697 PST | 1000000 | 1000.000 | 1.000000 | 2340925 | -8610877679.000000
- Thu Feb 16 17:32:01 1797 PST | 1000000 | 1000.000 | 1.000000 | 2377449 | -5455204079.000000
+ Tue Feb 16 17:32:01 0097 LMT BC | 1000000 | 1000.000 | 1.000000 | 1686043 | -65192682901.000000
+ Sat Feb 16 17:32:01 0097 LMT | 1000000 | 1000.000 | 1.000000 | 1756537 | -59102001301.000000
+ Thu Feb 16 17:32:01 0597 LMT | 1000000 | 1000.000 | 1.000000 | 1939158 | -43323546901.000000
+ Tue Feb 16 17:32:01 1097 LMT | 1000000 | 1000.000 | 1.000000 | 2121779 | -27545092501.000000
+ Sat Feb 16 17:32:01 1697 LMT | 1000000 | 1000.000 | 1.000000 | 2340925 | -8610878101.000000
+ Thu Feb 16 17:32:01 1797 LMT | 1000000 | 1000.000 | 1.000000 | 2377449 | -5455204501.000000
Tue Feb 16 17:32:01 1897 PST | 1000000 | 1000.000 | 1.000000 | 2413973 | -2299530479.000000
Sun Feb 16 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450497 | 856143121.000000
Sat Feb 16 17:32:01 2097 PST | 1000000 | 1000.000 | 1.000000 | 2487022 | 4011903121.000000
@@ -2304,7 +2304,7 @@
SELECT * FROM TIMESTAMPTZ_TST ORDER BY a;
a | b
---+--------------------------------
- 1 | Wed Mar 12 13:58:48 1000 PST
+ 1 | Wed Mar 12 14:05:50 1000 LMT
2 | Sun Mar 12 14:58:48 10000 PDT
3 | Sun Mar 12 14:58:48 100000 PDT
3 | Sun Mar 12 14:58:48 10000 PDT
diff -U3 /build/source/src/test/regress/expected/horology.out /build/source/build/testrun/regress/regress/results/horology.out
--- /build/source/src/test/regress/expected/horology.out 1970-01-01 00:00:01.000000000 +0000
+++ /build/source/build/testrun/regress/regress/results/horology.out 2024-09-13 17:58:09.785778080 +0000
@@ -1033,12 +1033,12 @@
Sat Feb 14 17:32:01 1998 PST
Sun Feb 15 17:32:01 1998 PST
Mon Feb 16 17:32:01 1998 PST
- Thu Feb 16 17:32:01 0096 PST BC
- Sun Feb 16 17:32:01 0098 PST
- Fri Feb 16 17:32:01 0598 PST
- Wed Feb 16 17:32:01 1098 PST
- Sun Feb 16 17:32:01 1698 PST
- Fri Feb 16 17:32:01 1798 PST
+ Thu Feb 16 17:32:01 0096 LMT BC
+ Sun Feb 16 17:32:01 0098 LMT
+ Fri Feb 16 17:32:01 0598 LMT
+ Wed Feb 16 17:32:01 1098 LMT
+ Sun Feb 16 17:32:01 1698 LMT
+ Fri Feb 16 17:32:01 1798 LMT
Wed Feb 16 17:32:01 1898 PST
Mon Feb 16 17:32:01 1998 PST
Sun Feb 16 17:32:01 2098 PST
@@ -1104,12 +1104,12 @@
Wed Feb 14 17:32:01 1996 PST
Thu Feb 15 17:32:01 1996 PST
Fri Feb 16 17:32:01 1996 PST
- Mon Feb 16 17:32:01 0098 PST BC
- Thu Feb 16 17:32:01 0096 PST
- Tue Feb 16 17:32:01 0596 PST
- Sun Feb 16 17:32:01 1096 PST
- Thu Feb 16 17:32:01 1696 PST
- Tue Feb 16 17:32:01 1796 PST
+ Mon Feb 16 17:32:01 0098 LMT BC
+ Thu Feb 16 17:32:01 0096 LMT
+ Tue Feb 16 17:32:01 0596 LMT
+ Sun Feb 16 17:32:01 1096 LMT
+ Thu Feb 16 17:32:01 1696 LMT
+ Tue Feb 16 17:32:01 1796 LMT
Sun Feb 16 17:32:01 1896 PST
Fri Feb 16 17:32:01 1996 PST
Thu Feb 16 17:32:01 2096 PST
@@ -2388,7 +2388,7 @@
SELECT '4714-11-24 BC'::date::timestamptz;
timestamptz
---------------------------------
- Mon Nov 24 00:00:00 4714 PST BC
+ Mon Nov 24 00:00:00 4714 LMT BC
(1 row)
SET TimeZone = 'UTC-2';
@@ -2966,13 +2966,13 @@
SELECT to_timestamp('0097/Feb/16 --> 08:14:30', 'YYYY/Mon/DD --> HH:MI:SS');
to_timestamp
------------------------------
- Sat Feb 16 08:14:30 0097 PST
+ Sat Feb 16 08:14:30 0097 LMT
(1 row)
SELECT to_timestamp('97/2/16 8:14:30', 'FMYYYY/FMMM/FMDD FMHH:FMMI:FMSS');
to_timestamp
------------------------------
- Sat Feb 16 08:14:30 0097 PST
+ Sat Feb 16 08:14:30 0097 LMT
(1 row)
SELECT to_timestamp('2011$03!18 23_38_15', 'YYYY-MM-DD HH24:MI:SS');
@@ -3009,7 +3009,7 @@
SELECT to_timestamp('1,582nd VIII 21', 'Y,YYYth FMRM DD');
to_timestamp
------------------------------
- Sat Aug 21 00:00:00 1582 PST
+ Sat Aug 21 00:00:00 1582 LMT
(1 row)
SELECT to_timestamp('15 "text between quote marks" 98 54 45',
@@ -3073,7 +3073,7 @@
SELECT to_timestamp('1997 BC 11 16', 'YYYY BC MM DD');
to_timestamp
---------------------------------
- Tue Nov 16 00:00:00 1997 PST BC
+ Tue Nov 16 00:00:00 1997 LMT BC
(1 row)
SELECT to_timestamp('1997 A.D. 11 16', 'YYYY B.C. MM DD');
@@ -3085,7 +3085,7 @@
SELECT to_timestamp('1997 B.C. 11 16', 'YYYY B.C. MM DD');
to_timestamp
---------------------------------
- Tue Nov 16 00:00:00 1997 PST BC
+ Tue Nov 16 00:00:00 1997 LMT BC
(1 row)
SELECT to_timestamp('9-1116', 'Y-MMDD');
@@ -3355,19 +3355,19 @@
SELECT to_timestamp('44-02-01 11:12:13 BC','YYYY-MM-DD HH24:MI:SS BC');
to_timestamp
---------------------------------
- Fri Feb 01 11:12:13 0044 PST BC
+ Fri Feb 01 11:12:13 0044 LMT BC
(1 row)
SELECT to_timestamp('-44-02-01 11:12:13','YYYY-MM-DD HH24:MI:SS');
to_timestamp
---------------------------------
- Fri Feb 01 11:12:13 0044 PST BC
+ Fri Feb 01 11:12:13 0044 LMT BC
(1 row)
SELECT to_timestamp('-44-02-01 11:12:13 BC','YYYY-MM-DD HH24:MI:SS BC');
to_timestamp
------------------------------
- Mon Feb 01 11:12:13 0044 PST
+ Mon Feb 01 11:12:13 0044 LMT
(1 row)
--
v1-0001-Run-regression-tests-with-timezone-America-Los_An.patchtext/x-patch; charset=UTF-8; name=v1-0001-Run-regression-tests-with-timezone-America-Los_An.patchDownload
From c5de73fbb86f7d600c90ba42ab9bd3d4eca34d1b Mon Sep 17 00:00:00 2001
From: Wolfgang Walther <walther@technowledgy.de>
Date: Sat, 14 Sep 2024 14:42:38 +0200
Subject: [PATCH v1] Run regression tests with timezone America/Los_Angeles
Previously, the regression tests were running with "PST8PDT", which was
changed to link to America/Los_Angeles in tzdata 2024b. Running the
tests --with-system-tzdata=2024b would therefore fail.
Run the regression tests with America/Los_Angeles to get consistent
output in both 2024a and 2024b.
---
doc/src/sgml/regress.sgml | 4 +-
src/test/regress/expected/date.out | 10 +-
src/test/regress/expected/horology.out | 48 ++++----
src/test/regress/expected/timestamptz.out | 128 +++++++++++-----------
src/test/regress/pg_regress.c | 2 +-
5 files changed, 96 insertions(+), 96 deletions(-)
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index d1042e02228..948e9bdd7cf 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -576,10 +576,10 @@ make check NO_LOCALE=1
<para>
Most of the date and time results are dependent on the time zone
environment. The reference files are generated for time zone
- <literal>PST8PDT</literal> (Berkeley, California), and there will be
+ <literal>America/Los_Angeles</literal>, and there will be
apparent failures if the tests are not run with that time zone setting.
The regression test driver sets environment variable
- <envar>PGTZ</envar> to <literal>PST8PDT</literal>, which normally
+ <envar>PGTZ</envar> to <literal>America/Los_Angeles</literal>, which normally
ensures proper results.
</para>
</sect2>
diff --git a/src/test/regress/expected/date.out b/src/test/regress/expected/date.out
index f5949f3d174..20374c5230a 100644
--- a/src/test/regress/expected/date.out
+++ b/src/test/regress/expected/date.out
@@ -1295,7 +1295,7 @@ SELECT DATE_TRUNC('MILLENNIUM', TIMESTAMP '1970-03-20 04:30:00.00000'); -- 1001
SELECT DATE_TRUNC('MILLENNIUM', DATE '1970-03-20'); -- 1001-01-01
date_trunc
------------------------------
- Thu Jan 01 00:00:00 1001 PST
+ Thu Jan 01 00:00:00 1001 LMT
(1 row)
SELECT DATE_TRUNC('CENTURY', TIMESTAMP '1970-03-20 04:30:00.00000'); -- 1901
@@ -1319,13 +1319,13 @@ SELECT DATE_TRUNC('CENTURY', DATE '2004-08-10'); -- 2001-01-01
SELECT DATE_TRUNC('CENTURY', DATE '0002-02-04'); -- 0001-01-01
date_trunc
------------------------------
- Mon Jan 01 00:00:00 0001 PST
+ Mon Jan 01 00:00:00 0001 LMT
(1 row)
SELECT DATE_TRUNC('CENTURY', DATE '0055-08-10 BC'); -- 0100-01-01 BC
date_trunc
---------------------------------
- Tue Jan 01 00:00:00 0100 PST BC
+ Tue Jan 01 00:00:00 0100 LMT BC
(1 row)
SELECT DATE_TRUNC('DECADE', DATE '1993-12-25'); -- 1990-01-01
@@ -1337,13 +1337,13 @@ SELECT DATE_TRUNC('DECADE', DATE '1993-12-25'); -- 1990-01-01
SELECT DATE_TRUNC('DECADE', DATE '0004-12-25'); -- 0001-01-01 BC
date_trunc
---------------------------------
- Sat Jan 01 00:00:00 0001 PST BC
+ Sat Jan 01 00:00:00 0001 LMT BC
(1 row)
SELECT DATE_TRUNC('DECADE', DATE '0002-12-31 BC'); -- 0011-01-01 BC
date_trunc
---------------------------------
- Mon Jan 01 00:00:00 0011 PST BC
+ Mon Jan 01 00:00:00 0011 LMT BC
(1 row)
--
diff --git a/src/test/regress/expected/horology.out b/src/test/regress/expected/horology.out
index 58da26ab0e1..82c0e1a12f2 100644
--- a/src/test/regress/expected/horology.out
+++ b/src/test/regress/expected/horology.out
@@ -2,9 +2,9 @@
-- HOROLOGY
--
SHOW TimeZone; -- Many of these tests depend on the prevailing settings
- TimeZone
-----------
- PST8PDT
+ TimeZone
+---------------------
+ America/Los_Angeles
(1 row)
SHOW DateStyle;
@@ -1038,12 +1038,12 @@ SELECT d1 + interval '1 year' AS one_year FROM TIMESTAMPTZ_TBL;
Sat Feb 14 17:32:01 1998 PST
Sun Feb 15 17:32:01 1998 PST
Mon Feb 16 17:32:01 1998 PST
- Thu Feb 16 17:32:01 0096 PST BC
- Sun Feb 16 17:32:01 0098 PST
- Fri Feb 16 17:32:01 0598 PST
- Wed Feb 16 17:32:01 1098 PST
- Sun Feb 16 17:32:01 1698 PST
- Fri Feb 16 17:32:01 1798 PST
+ Thu Feb 16 17:32:01 0096 LMT BC
+ Sun Feb 16 17:32:01 0098 LMT
+ Fri Feb 16 17:32:01 0598 LMT
+ Wed Feb 16 17:32:01 1098 LMT
+ Sun Feb 16 17:32:01 1698 LMT
+ Fri Feb 16 17:32:01 1798 LMT
Wed Feb 16 17:32:01 1898 PST
Mon Feb 16 17:32:01 1998 PST
Sun Feb 16 17:32:01 2098 PST
@@ -1109,12 +1109,12 @@ SELECT d1 - interval '1 year' AS one_year FROM TIMESTAMPTZ_TBL;
Wed Feb 14 17:32:01 1996 PST
Thu Feb 15 17:32:01 1996 PST
Fri Feb 16 17:32:01 1996 PST
- Mon Feb 16 17:32:01 0098 PST BC
- Thu Feb 16 17:32:01 0096 PST
- Tue Feb 16 17:32:01 0596 PST
- Sun Feb 16 17:32:01 1096 PST
- Thu Feb 16 17:32:01 1696 PST
- Tue Feb 16 17:32:01 1796 PST
+ Mon Feb 16 17:32:01 0098 LMT BC
+ Thu Feb 16 17:32:01 0096 LMT
+ Tue Feb 16 17:32:01 0596 LMT
+ Sun Feb 16 17:32:01 1096 LMT
+ Thu Feb 16 17:32:01 1696 LMT
+ Tue Feb 16 17:32:01 1796 LMT
Sun Feb 16 17:32:01 1896 PST
Fri Feb 16 17:32:01 1996 PST
Thu Feb 16 17:32:01 2096 PST
@@ -2470,7 +2470,7 @@ SELECT '2020-10-05'::timestamptz > '2202020-10-05'::date as f;
SELECT '4714-11-24 BC'::date::timestamptz;
timestamptz
---------------------------------
- Mon Nov 24 00:00:00 4714 PST BC
+ Mon Nov 24 00:00:00 4714 LMT BC
(1 row)
SET TimeZone = 'UTC-2';
@@ -3048,13 +3048,13 @@ RESET DateStyle;
SELECT to_timestamp('0097/Feb/16 --> 08:14:30', 'YYYY/Mon/DD --> HH:MI:SS');
to_timestamp
------------------------------
- Sat Feb 16 08:14:30 0097 PST
+ Sat Feb 16 08:14:30 0097 LMT
(1 row)
SELECT to_timestamp('97/2/16 8:14:30', 'FMYYYY/FMMM/FMDD FMHH:FMMI:FMSS');
to_timestamp
------------------------------
- Sat Feb 16 08:14:30 0097 PST
+ Sat Feb 16 08:14:30 0097 LMT
(1 row)
SELECT to_timestamp('2011$03!18 23_38_15', 'YYYY-MM-DD HH24:MI:SS');
@@ -3091,7 +3091,7 @@ SELECT to_timestamp('My birthday-> Year: 1976, Month: May, Day: 16',
SELECT to_timestamp('1,582nd VIII 21', 'Y,YYYth FMRM DD');
to_timestamp
------------------------------
- Sat Aug 21 00:00:00 1582 PST
+ Sat Aug 21 00:00:00 1582 LMT
(1 row)
SELECT to_timestamp('15 "text between quote marks" 98 54 45',
@@ -3155,7 +3155,7 @@ SELECT to_timestamp('1997 AD 11 16', 'YYYY BC MM DD');
SELECT to_timestamp('1997 BC 11 16', 'YYYY BC MM DD');
to_timestamp
---------------------------------
- Tue Nov 16 00:00:00 1997 PST BC
+ Tue Nov 16 00:00:00 1997 LMT BC
(1 row)
SELECT to_timestamp('1997 A.D. 11 16', 'YYYY B.C. MM DD');
@@ -3167,7 +3167,7 @@ SELECT to_timestamp('1997 A.D. 11 16', 'YYYY B.C. MM DD');
SELECT to_timestamp('1997 B.C. 11 16', 'YYYY B.C. MM DD');
to_timestamp
---------------------------------
- Tue Nov 16 00:00:00 1997 PST BC
+ Tue Nov 16 00:00:00 1997 LMT BC
(1 row)
SELECT to_timestamp('9-1116', 'Y-MMDD');
@@ -3495,19 +3495,19 @@ SELECT to_date('-44-02-01 BC','YYYY-MM-DD BC');
SELECT to_timestamp('44-02-01 11:12:13 BC','YYYY-MM-DD HH24:MI:SS BC');
to_timestamp
---------------------------------
- Fri Feb 01 11:12:13 0044 PST BC
+ Fri Feb 01 11:12:13 0044 LMT BC
(1 row)
SELECT to_timestamp('-44-02-01 11:12:13','YYYY-MM-DD HH24:MI:SS');
to_timestamp
---------------------------------
- Fri Feb 01 11:12:13 0044 PST BC
+ Fri Feb 01 11:12:13 0044 LMT BC
(1 row)
SELECT to_timestamp('-44-02-01 11:12:13 BC','YYYY-MM-DD HH24:MI:SS BC');
to_timestamp
------------------------------
- Mon Feb 01 11:12:13 0044 PST
+ Mon Feb 01 11:12:13 0044 LMT
(1 row)
--
diff --git a/src/test/regress/expected/timestamptz.out b/src/test/regress/expected/timestamptz.out
index d01d174983e..5e5d601a35d 100644
--- a/src/test/regress/expected/timestamptz.out
+++ b/src/test/regress/expected/timestamptz.out
@@ -330,12 +330,12 @@ SELECT d1 FROM TIMESTAMPTZ_TBL;
Fri Feb 14 17:32:01 1997 PST
Sat Feb 15 17:32:01 1997 PST
Sun Feb 16 17:32:01 1997 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Sun Feb 16 17:32:01 1997 PST
Sat Feb 16 17:32:01 2097 PST
@@ -359,19 +359,19 @@ SELECT d1 FROM TIMESTAMPTZ_TBL;
SELECT '4714-11-24 00:00:00+00 BC'::timestamptz;
timestamptz
---------------------------------
- Sun Nov 23 16:00:00 4714 PST BC
+ Sun Nov 23 16:07:02 4714 LMT BC
(1 row)
SELECT '4714-11-23 16:00:00-08 BC'::timestamptz;
timestamptz
---------------------------------
- Sun Nov 23 16:00:00 4714 PST BC
+ Sun Nov 23 16:07:02 4714 LMT BC
(1 row)
SELECT 'Sun Nov 23 16:00:00 4714 PST BC'::timestamptz;
timestamptz
---------------------------------
- Sun Nov 23 16:00:00 4714 PST BC
+ Sun Nov 23 16:07:02 4714 LMT BC
(1 row)
SELECT '4714-11-23 23:59:59+00 BC'::timestamptz; -- out of range
@@ -461,12 +461,12 @@ SELECT d1 FROM TIMESTAMPTZ_TBL
---------------------------------
-infinity
Wed Dec 31 16:00:00 1969 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Wed Feb 28 17:32:01 1996 PST
Thu Feb 29 17:32:01 1996 PST
@@ -529,12 +529,12 @@ SELECT d1 FROM TIMESTAMPTZ_TBL
Fri Feb 14 17:32:01 1997 PST
Sat Feb 15 17:32:01 1997 PST
Sun Feb 16 17:32:01 1997 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Sun Feb 16 17:32:01 1997 PST
Sat Feb 16 17:32:01 2097 PST
@@ -561,12 +561,12 @@ SELECT d1 FROM TIMESTAMPTZ_TBL
-infinity
Wed Dec 31 16:00:00 1969 PST
Thu Jan 02 00:00:00 1997 PST
- Tue Feb 16 17:32:01 0097 PST BC
- Sat Feb 16 17:32:01 0097 PST
- Thu Feb 16 17:32:01 0597 PST
- Tue Feb 16 17:32:01 1097 PST
- Sat Feb 16 17:32:01 1697 PST
- Thu Feb 16 17:32:01 1797 PST
+ Tue Feb 16 17:32:01 0097 LMT BC
+ Sat Feb 16 17:32:01 0097 LMT
+ Thu Feb 16 17:32:01 0597 LMT
+ Tue Feb 16 17:32:01 1097 LMT
+ Sat Feb 16 17:32:01 1697 LMT
+ Thu Feb 16 17:32:01 1797 LMT
Tue Feb 16 17:32:01 1897 PST
Wed Feb 28 17:32:01 1996 PST
Thu Feb 29 17:32:01 1996 PST
@@ -920,12 +920,12 @@ SELECT d1 as timestamptz,
Fri Feb 14 17:32:01 1997 PST | 1997 | 2 | 14 | 17 | 32 | 1
Sat Feb 15 17:32:01 1997 PST | 1997 | 2 | 15 | 17 | 32 | 1
Sun Feb 16 17:32:01 1997 PST | 1997 | 2 | 16 | 17 | 32 | 1
- Tue Feb 16 17:32:01 0097 PST BC | -97 | 2 | 16 | 17 | 32 | 1
- Sat Feb 16 17:32:01 0097 PST | 97 | 2 | 16 | 17 | 32 | 1
- Thu Feb 16 17:32:01 0597 PST | 597 | 2 | 16 | 17 | 32 | 1
- Tue Feb 16 17:32:01 1097 PST | 1097 | 2 | 16 | 17 | 32 | 1
- Sat Feb 16 17:32:01 1697 PST | 1697 | 2 | 16 | 17 | 32 | 1
- Thu Feb 16 17:32:01 1797 PST | 1797 | 2 | 16 | 17 | 32 | 1
+ Tue Feb 16 17:32:01 0097 LMT BC | -97 | 2 | 16 | 17 | 32 | 1
+ Sat Feb 16 17:32:01 0097 LMT | 97 | 2 | 16 | 17 | 32 | 1
+ Thu Feb 16 17:32:01 0597 LMT | 597 | 2 | 16 | 17 | 32 | 1
+ Tue Feb 16 17:32:01 1097 LMT | 1097 | 2 | 16 | 17 | 32 | 1
+ Sat Feb 16 17:32:01 1697 LMT | 1697 | 2 | 16 | 17 | 32 | 1
+ Thu Feb 16 17:32:01 1797 LMT | 1797 | 2 | 16 | 17 | 32 | 1
Tue Feb 16 17:32:01 1897 PST | 1897 | 2 | 16 | 17 | 32 | 1
Sun Feb 16 17:32:01 1997 PST | 1997 | 2 | 16 | 17 | 32 | 1
Sat Feb 16 17:32:01 2097 PST | 2097 | 2 | 16 | 17 | 32 | 1
@@ -994,12 +994,12 @@ SELECT d1 as timestamptz,
Fri Feb 14 17:32:01 1997 PST | 1 | 1000 | 1000000
Sat Feb 15 17:32:01 1997 PST | 1 | 1000 | 1000000
Sun Feb 16 17:32:01 1997 PST | 1 | 1000 | 1000000
- Tue Feb 16 17:32:01 0097 PST BC | 1 | 1000 | 1000000
- Sat Feb 16 17:32:01 0097 PST | 1 | 1000 | 1000000
- Thu Feb 16 17:32:01 0597 PST | 1 | 1000 | 1000000
- Tue Feb 16 17:32:01 1097 PST | 1 | 1000 | 1000000
- Sat Feb 16 17:32:01 1697 PST | 1 | 1000 | 1000000
- Thu Feb 16 17:32:01 1797 PST | 1 | 1000 | 1000000
+ Tue Feb 16 17:32:01 0097 LMT BC | 1 | 1000 | 1000000
+ Sat Feb 16 17:32:01 0097 LMT | 1 | 1000 | 1000000
+ Thu Feb 16 17:32:01 0597 LMT | 1 | 1000 | 1000000
+ Tue Feb 16 17:32:01 1097 LMT | 1 | 1000 | 1000000
+ Sat Feb 16 17:32:01 1697 LMT | 1 | 1000 | 1000000
+ Thu Feb 16 17:32:01 1797 LMT | 1 | 1000 | 1000000
Tue Feb 16 17:32:01 1897 PST | 1 | 1000 | 1000000
Sun Feb 16 17:32:01 1997 PST | 1 | 1000 | 1000000
Sat Feb 16 17:32:01 2097 PST | 1 | 1000 | 1000000
@@ -1069,12 +1069,12 @@ SELECT d1 as timestamptz,
Fri Feb 14 17:32:01 1997 PST | 1997 | 7 | 5 | 5 | 45
Sat Feb 15 17:32:01 1997 PST | 1997 | 7 | 6 | 6 | 46
Sun Feb 16 17:32:01 1997 PST | 1997 | 7 | 7 | 0 | 47
- Tue Feb 16 17:32:01 0097 PST BC | -97 | 7 | 2 | 2 | 47
- Sat Feb 16 17:32:01 0097 PST | 97 | 7 | 6 | 6 | 47
- Thu Feb 16 17:32:01 0597 PST | 597 | 7 | 4 | 4 | 47
- Tue Feb 16 17:32:01 1097 PST | 1097 | 7 | 2 | 2 | 47
- Sat Feb 16 17:32:01 1697 PST | 1697 | 7 | 6 | 6 | 47
- Thu Feb 16 17:32:01 1797 PST | 1797 | 7 | 4 | 4 | 47
+ Tue Feb 16 17:32:01 0097 LMT BC | -97 | 7 | 2 | 2 | 47
+ Sat Feb 16 17:32:01 0097 LMT | 97 | 7 | 6 | 6 | 47
+ Thu Feb 16 17:32:01 0597 LMT | 597 | 7 | 4 | 4 | 47
+ Tue Feb 16 17:32:01 1097 LMT | 1097 | 7 | 2 | 2 | 47
+ Sat Feb 16 17:32:01 1697 LMT | 1697 | 7 | 6 | 6 | 47
+ Thu Feb 16 17:32:01 1797 LMT | 1797 | 7 | 4 | 4 | 47
Tue Feb 16 17:32:01 1897 PST | 1897 | 7 | 2 | 2 | 47
Sun Feb 16 17:32:01 1997 PST | 1997 | 7 | 7 | 0 | 47
Sat Feb 16 17:32:01 2097 PST | 2097 | 7 | 6 | 6 | 47
@@ -1146,12 +1146,12 @@ SELECT d1 as timestamptz,
Fri Feb 14 17:32:01 1997 PST | 199 | 20 | 2 | 2450495 | 855970321
Sat Feb 15 17:32:01 1997 PST | 199 | 20 | 2 | 2450496 | 856056721
Sun Feb 16 17:32:01 1997 PST | 199 | 20 | 2 | 2450497 | 856143121
- Tue Feb 16 17:32:01 0097 PST BC | -10 | -1 | -1 | 1686043 | -65192682479
- Sat Feb 16 17:32:01 0097 PST | 9 | 1 | 1 | 1756537 | -59102000879
- Thu Feb 16 17:32:01 0597 PST | 59 | 6 | 1 | 1939158 | -43323546479
- Tue Feb 16 17:32:01 1097 PST | 109 | 11 | 2 | 2121779 | -27545092079
- Sat Feb 16 17:32:01 1697 PST | 169 | 17 | 2 | 2340925 | -8610877679
- Thu Feb 16 17:32:01 1797 PST | 179 | 18 | 2 | 2377449 | -5455204079
+ Tue Feb 16 17:32:01 0097 LMT BC | -10 | -1 | -1 | 1686043 | -65192682901
+ Sat Feb 16 17:32:01 0097 LMT | 9 | 1 | 1 | 1756537 | -59102001301
+ Thu Feb 16 17:32:01 0597 LMT | 59 | 6 | 1 | 1939158 | -43323546901
+ Tue Feb 16 17:32:01 1097 LMT | 109 | 11 | 2 | 2121779 | -27545092501
+ Sat Feb 16 17:32:01 1697 LMT | 169 | 17 | 2 | 2340925 | -8610878101
+ Thu Feb 16 17:32:01 1797 LMT | 179 | 18 | 2 | 2377449 | -5455204501
Tue Feb 16 17:32:01 1897 PST | 189 | 19 | 2 | 2413973 | -2299530479
Sun Feb 16 17:32:01 1997 PST | 199 | 20 | 2 | 2450497 | 856143121
Sat Feb 16 17:32:01 2097 PST | 209 | 21 | 3 | 2487022 | 4011903121
@@ -1221,12 +1221,12 @@ SELECT d1 as timestamptz,
Fri Feb 14 17:32:01 1997 PST | -28800 | -8 | 0
Sat Feb 15 17:32:01 1997 PST | -28800 | -8 | 0
Sun Feb 16 17:32:01 1997 PST | -28800 | -8 | 0
- Tue Feb 16 17:32:01 0097 PST BC | -28800 | -8 | 0
- Sat Feb 16 17:32:01 0097 PST | -28800 | -8 | 0
- Thu Feb 16 17:32:01 0597 PST | -28800 | -8 | 0
- Tue Feb 16 17:32:01 1097 PST | -28800 | -8 | 0
- Sat Feb 16 17:32:01 1697 PST | -28800 | -8 | 0
- Thu Feb 16 17:32:01 1797 PST | -28800 | -8 | 0
+ Tue Feb 16 17:32:01 0097 LMT BC | -28378 | -7 | -52
+ Sat Feb 16 17:32:01 0097 LMT | -28378 | -7 | -52
+ Thu Feb 16 17:32:01 0597 LMT | -28378 | -7 | -52
+ Tue Feb 16 17:32:01 1097 LMT | -28378 | -7 | -52
+ Sat Feb 16 17:32:01 1697 LMT | -28378 | -7 | -52
+ Thu Feb 16 17:32:01 1797 LMT | -28378 | -7 | -52
Tue Feb 16 17:32:01 1897 PST | -28800 | -8 | 0
Sun Feb 16 17:32:01 1997 PST | -28800 | -8 | 0
Sat Feb 16 17:32:01 2097 PST | -28800 | -8 | 0
@@ -1300,12 +1300,12 @@ SELECT d1 as "timestamp",
Fri Feb 14 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450495 | 855970321.000000
Sat Feb 15 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450496 | 856056721.000000
Sun Feb 16 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450497 | 856143121.000000
- Tue Feb 16 17:32:01 0097 PST BC | 1000000 | 1000.000 | 1.000000 | 1686043 | -65192682479.000000
- Sat Feb 16 17:32:01 0097 PST | 1000000 | 1000.000 | 1.000000 | 1756537 | -59102000879.000000
- Thu Feb 16 17:32:01 0597 PST | 1000000 | 1000.000 | 1.000000 | 1939158 | -43323546479.000000
- Tue Feb 16 17:32:01 1097 PST | 1000000 | 1000.000 | 1.000000 | 2121779 | -27545092079.000000
- Sat Feb 16 17:32:01 1697 PST | 1000000 | 1000.000 | 1.000000 | 2340925 | -8610877679.000000
- Thu Feb 16 17:32:01 1797 PST | 1000000 | 1000.000 | 1.000000 | 2377449 | -5455204079.000000
+ Tue Feb 16 17:32:01 0097 LMT BC | 1000000 | 1000.000 | 1.000000 | 1686043 | -65192682901.000000
+ Sat Feb 16 17:32:01 0097 LMT | 1000000 | 1000.000 | 1.000000 | 1756537 | -59102001301.000000
+ Thu Feb 16 17:32:01 0597 LMT | 1000000 | 1000.000 | 1.000000 | 1939158 | -43323546901.000000
+ Tue Feb 16 17:32:01 1097 LMT | 1000000 | 1000.000 | 1.000000 | 2121779 | -27545092501.000000
+ Sat Feb 16 17:32:01 1697 LMT | 1000000 | 1000.000 | 1.000000 | 2340925 | -8610878101.000000
+ Thu Feb 16 17:32:01 1797 LMT | 1000000 | 1000.000 | 1.000000 | 2377449 | -5455204501.000000
Tue Feb 16 17:32:01 1897 PST | 1000000 | 1000.000 | 1.000000 | 2413973 | -2299530479.000000
Sun Feb 16 17:32:01 1997 PST | 1000000 | 1000.000 | 1.000000 | 2450497 | 856143121.000000
Sat Feb 16 17:32:01 2097 PST | 1000000 | 1000.000 | 1.000000 | 2487022 | 4011903121.000000
@@ -2304,7 +2304,7 @@ INSERT INTO TIMESTAMPTZ_TST VALUES(4, '1000000312 23:58:48 IST');
SELECT * FROM TIMESTAMPTZ_TST ORDER BY a;
a | b
---+--------------------------------
- 1 | Wed Mar 12 13:58:48 1000 PST
+ 1 | Wed Mar 12 14:05:50 1000 LMT
2 | Sun Mar 12 14:58:48 10000 PDT
3 | Sun Mar 12 14:58:48 100000 PDT
3 | Sun Mar 12 14:58:48 10000 PDT
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 69a0caffa47..5157629b1cc 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -776,7 +776,7 @@ initialize_environment(void)
/*
* Set timezone and datestyle for datetime-related tests
*/
- setenv("PGTZ", "PST8PDT", 1);
+ setenv("PGTZ", "America/Los_Angeles", 1);
setenv("PGDATESTYLE", "Postgres, MDY", 1);
/*
--
2.46.0
Wolfgang Walther <walther@technowledgy.de> writes:
Building --with-system-tzdata and the latest tzdata 2024b fails the
regression tests for me (see attached .diffs). This seems to be because
of [1], which changed the way "PST8PDT" is handled. This is the timezone
that the regression tests are run with.
That's quite annoying, especially since it was not mentioned in the
2024b release notes. (I had read the notes and concluded that 2024b
didn't require any immediate attention on our part.)
From 2024b on, "PST8PDT" is the same as "America/Los_Angeles", so by
changing the regression tests to use the latter as the default, we're
getting consistent output on at least 2024a and 2024b.
I'm fairly un-thrilled with this answer, not least because it exposes
that zone's idiosyncratic "LMT" offset of -7:52:58 for years before
1883. (I'm surprised that that seems to affect only one or two
regression results.) Also, as a real place to a greater extent
than "PST8PDT" is, it's more subject to historical revisionism when
somebody turns up evidence of local law having been different than
TZDB currently thinks.
We may not have a lot of choice though. I experimented with using
full POSIX notation, that is "PST8PDT,M3.2.0,M11.1.0", but that is
actually worse in terms of the number of test diffs, since it doesn't
match the DST transition dates that the tests expect for years before
2007. Another objection is that the tests would then not exercise any
of the mainstream tzdb-file-reading code paths within the timezone
code itself.
Grumble.
regards, tom lane
Tom Lane:
Also, as a real place to a greater extent
than "PST8PDT" is, it's more subject to historical revisionism when
somebody turns up evidence of local law having been different than
TZDB currently thinks.
I now tried all versions of tzdata which we had in tree back to 2018g,
they all work fine with the same regression test output. 2018g was an
arbitrary cutoff, I just didn't try any further.
In the end, we don't need a default timezone that will never change. We
just need one that didn't change in a reasonable number of releases
going backwards. Once America/Los_Angeles is changed, we need to switch
to a different zone, which could be one that wouldn't work today. Kind
of a sliding window.
One positive might be: With this timezone, we are more likely to see
relevant changes mentioned in the upstream release notes.
Best,
Wolfgang
Wolfgang Walther <walther@technowledgy.de> writes:
Tom Lane:
Also, as a real place to a greater extent
than "PST8PDT" is, it's more subject to historical revisionism when
somebody turns up evidence of local law having been different than
TZDB currently thinks.
I now tried all versions of tzdata which we had in tree back to 2018g,
they all work fine with the same regression test output. 2018g was an
arbitrary cutoff, I just didn't try any further.
Yeah, my belly-aching above is just about hypothetical future
instability. In reality, I'm sure America/Los_Angeles is pretty
well researched and so it's unlikely that there will be unexpected
changes in its zone history.
In the end, we don't need a default timezone that will never change.
We do, really. For example, there's a nonzero chance the USA will
cancel DST altogether at some future time. (This would be driven by
politicians who don't remember the last time, but there's no shortage
of those.) That'd likely break some of our test results, and even if
it happened not to, it'd still be bad because we'd probably lose some
coverage of the DST-transition-related code paths in src/timezone/.
So I'd really be way happier with a test timezone that never changes
but does include DST behavior. I thought PST8PDT fit those
requirements pretty well, and I'm annoyed at Eggert for having tossed
it overboard for no benefit whatever. But I don't run tzdb, so
here we are.
We just need one that didn't change in a reasonable number of
releases going backwards.
We've had this sort of fire-drill before, e.g. commit 8d7af8fbe.
It's no fun, and the potential surface area for unexpected changes
is now much greater than the few tests affected by that change.
But here we are, so I pushed your patch with a couple of other
cosmetic bits. There are still a couple of references to PST8PDT
in the tree, but they don't appear to care what the actual meaning
of that zone is, so I left them be.
regards, tom lane
On Mon, Sep 16, 2024 at 7:09 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Wolfgang Walther <walther@technowledgy.de> writes:
Tom Lane:
Also, as a real place to a greater extent
than "PST8PDT" is, it's more subject to historical revisionism when
somebody turns up evidence of local law having been different than
TZDB currently thinks.I now tried all versions of tzdata which we had in tree back to 2018g,
they all work fine with the same regression test output. 2018g was an
arbitrary cutoff, I just didn't try any further.Yeah, my belly-aching above is just about hypothetical future
instability. In reality, I'm sure America/Los_Angeles is pretty
well researched and so it's unlikely that there will be unexpected
changes in its zone history.In the end, we don't need a default timezone that will never change.
We do, really. For example, there's a nonzero chance the USA will
cancel DST altogether at some future time. (This would be driven by
politicians who don't remember the last time, but there's no shortage
of those.) That'd likely break some of our test results, and even if
it happened not to, it'd still be bad because we'd probably lose some
coverage of the DST-transition-related code paths in src/timezone/.
So I'd really be way happier with a test timezone that never changes
but does include DST behavior. I thought PST8PDT fit those
requirements pretty well, and I'm annoyed at Eggert for having tossed
it overboard for no benefit whatever. But I don't run tzdb, so
here we are.We just need one that didn't change in a reasonable number of
releases going backwards.We've had this sort of fire-drill before, e.g. commit 8d7af8fbe.
It's no fun, and the potential surface area for unexpected changes
is now much greater than the few tests affected by that change.But here we are, so I pushed your patch with a couple of other
cosmetic bits. There are still a couple of references to PST8PDT
in the tree, but they don't appear to care what the actual meaning
of that zone is, so I left them be.
This is an unfortunate change as this will break extensions tests using
pg_regress for testing. We run our tests against multiple minor versions
and this getting backported means our tests will fail with the next minor
pg release. Is there a workaround available to make the timezone for
pg_regress configurable without going into every test?
Regards, Sven Klemm
Sven Klemm <sven@timescale.com> writes:
This is an unfortunate change as this will break extensions tests using
pg_regress for testing. We run our tests against multiple minor versions
and this getting backported means our tests will fail with the next minor
pg release. Is there a workaround available to make the timezone for
pg_regress configurable without going into every test?
Configurable to what? If your test cases are dependent on the
historical behavior of PST8PDT, you're out of luck, because that
simply isn't available anymore (or won't be once 2024b reaches
your platform, anyway).
regards, tom lane
On Mon, Sep 16, 2024 at 5:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Configurable to what? If your test cases are dependent on the
historical behavior of PST8PDT, you're out of luck, because that
simply isn't available anymore (or won't be once 2024b reaches
your platform, anyway).
I was wondering whether the timezone used by pg_regress could be made
configurable.
--
Regards, Sven Klemm
Sven Klemm <sven@timescale.com> writes:
On Mon, Sep 16, 2024 at 5:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Configurable to what? If your test cases are dependent on the
historical behavior of PST8PDT, you're out of luck, because that
simply isn't available anymore (or won't be once 2024b reaches
your platform, anyway).
I was wondering whether the timezone used by pg_regress could be made
configurable.
Yes, I understood that you were suggesting that. My point is that
it wouldn't do you any good: you will still have to change any
regression test cases that depend on behavior PST8PDT has/had that
is different from America/Los_Angeles. That being the case,
I don't see much value in making it configurable.
regards, tom lane
Tom Lane:
I was wondering whether the timezone used by pg_regress could be made
configurable.Yes, I understood that you were suggesting that. My point is that
it wouldn't do you any good: you will still have to change any
regression test cases that depend on behavior PST8PDT has/had that
is different from America/Los_Angeles. That being the case,
I don't see much value in making it configurable.
Just changing it back to PST8PDT wouldn't really help as Tom pointed
out. You'd still get different results depending on which tzdata version
you are running with.
The core regression tests need to be run with a timezone that tests
special cases in the timezone handling code. But that might not be true
for extensions - all they want could be a stable output across major and
minor versions of postgres and versions of tzdata. It could be helpful
to set pg_regress' timezone to UTC, for example?
Best,
Wolfgang
Wolfgang Walther <walther@technowledgy.de> writes:
The core regression tests need to be run with a timezone that tests
special cases in the timezone handling code. But that might not be true
for extensions - all they want could be a stable output across major and
minor versions of postgres and versions of tzdata. It could be helpful
to set pg_regress' timezone to UTC, for example?
I would not recommend that choice. It would mask simple errors such
as failing to apply the correct conversion between timestamptz and
timestamp values. Also, if you have test cases that are affected by
this issue at all, you probably have a need/desire to test things like
DST transitions.
regards, tom lane
On Tue, Sep 17, 2024 at 4:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Wolfgang Walther <walther@technowledgy.de> writes:
The core regression tests need to be run with a timezone that tests
special cases in the timezone handling code. But that might not be true
for extensions - all they want could be a stable output across major and
minor versions of postgres and versions of tzdata. It could be helpful
to set pg_regress' timezone to UTC, for example?I would not recommend that choice. It would mask simple errors such
as failing to apply the correct conversion between timestamptz and
timestamp values. Also, if you have test cases that are affected by
this issue at all, you probably have a need/desire to test things like
DST transitions.
As far as I'm aware timescaledb does not rely on specifics of tzdata
version but just needs a stable setting for timezone. I guess I'll adjust
our tests to not depend on upstream pg_regress timezone.
--
Regards, Sven Klemm