2001-09-28 10:00:11 +02:00
|
|
|
--
|
|
|
|
-- TIMESTAMPTZ
|
|
|
|
--
|
|
|
|
|
2008-05-25 23:51:00 +02:00
|
|
|
CREATE TABLE TIMESTAMPTZ_TBL (d1 timestamp(2) with time zone);
|
|
|
|
|
|
|
|
-- Test shorthand input values
|
|
|
|
-- We can't just "select" the results since they aren't constants; test for
|
|
|
|
-- equality instead. We can do that by running the test inside a transaction
|
|
|
|
-- block, within which the value of 'now' shouldn't change. We also check
|
|
|
|
-- that 'now' *does* change over a reasonable interval such as 100 msec.
|
|
|
|
-- NOTE: it is possible for this part of the test to fail if the transaction
|
|
|
|
-- block is entered exactly at local midnight; then 'now' and 'today' have
|
|
|
|
-- the same values and the counts will come out different.
|
|
|
|
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
|
|
|
|
SELECT pg_sleep(0.1);
|
|
|
|
|
|
|
|
BEGIN;
|
2001-09-28 10:00:11 +02:00
|
|
|
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('today');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('yesterday');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('tomorrow');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('tomorrow EST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('tomorrow zulu');
|
|
|
|
|
|
|
|
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'today';
|
|
|
|
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'tomorrow';
|
|
|
|
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'yesterday';
|
2008-05-25 23:51:00 +02:00
|
|
|
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp(2) with time zone 'now';
|
|
|
|
|
|
|
|
COMMIT;
|
2001-09-28 10:00:11 +02:00
|
|
|
|
|
|
|
DELETE FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
-- verify uniform transaction time within transaction block
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
|
2008-05-25 23:51:00 +02:00
|
|
|
SELECT pg_sleep(0.1);
|
2001-09-28 10:00:11 +02:00
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
|
2008-05-25 23:51:00 +02:00
|
|
|
SELECT pg_sleep(0.1);
|
2001-10-04 16:51:06 +02:00
|
|
|
SELECT count(*) AS two FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp(2) with time zone 'now';
|
2008-05-25 23:51:00 +02:00
|
|
|
COMMIT;
|
|
|
|
|
2001-09-28 10:00:11 +02:00
|
|
|
DELETE FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
-- Special values
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('-infinity');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('infinity');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('epoch');
|
|
|
|
-- Obsolete special values
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('invalid');
|
2009-03-22 02:12:32 +01:00
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('undefined');
|
2008-05-25 23:51:00 +02:00
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('current');
|
2001-09-28 10:00:11 +02:00
|
|
|
|
|
|
|
-- Postgres v6.0 standard output format
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mon Feb 10 17:32:01 1997 PST');
|
|
|
|
|
|
|
|
-- Variations on Postgres v6.1 standard output format
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mon Feb 10 17:32:01.000001 1997 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mon Feb 10 17:32:01.999999 1997 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mon Feb 10 17:32:01.4 1997 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mon Feb 10 17:32:01.5 1997 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mon Feb 10 17:32:01.6 1997 PST');
|
|
|
|
|
|
|
|
-- ISO 8601 format
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-01-02');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-01-02 03:04:05');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-02-10 17:32:01-08');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-02-10 17:32:01-0800');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-02-10 17:32:01 -08:00');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('19970210 173201 -0800');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-06-10 17:32:01 -07:00');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2001-09-22T18:19:20');
|
|
|
|
|
2006-10-17 23:03:21 +02:00
|
|
|
-- POSIX format (note that the timezone abbrev is just decoration here)
|
2001-09-28 10:00:11 +02:00
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 08:14:01 GMT+8');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 13:14:02 GMT-1');
|
2006-10-17 23:03:21 +02:00
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 12:14:03 GMT-2');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 03:14:04 PST+8');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 02:14:05 MST+7:00');
|
2001-09-28 10:00:11 +02:00
|
|
|
|
|
|
|
-- Variations for acceptable input formats
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 10 17:32:01 1997 -0800');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 10 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 10 5:32PM 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997/02/10 17:32:01-0800');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-02-10 17:32:01 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb-10-1997 17:32:01 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('02-10-1997 17:32:01 PST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('19970210 173201 PST');
|
2003-07-29 02:03:19 +02:00
|
|
|
set datestyle to ymd;
|
2001-09-28 10:00:11 +02:00
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('97FEB10 5:32:01PM UTC');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('97/02/10 17:32:01 UTC');
|
2003-07-29 02:03:19 +02:00
|
|
|
reset datestyle;
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997.041 17:32:01 UTC');
|
2001-09-28 10:00:11 +02:00
|
|
|
|
2006-07-06 03:46:38 +02:00
|
|
|
-- timestamps at different timezones
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('19970210 173201 America/New_York');
|
|
|
|
SELECT '19970210 173201' AT TIME ZONE 'America/New_York';
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('19970710 173201 America/New_York');
|
|
|
|
SELECT '19970710 173201' AT TIME ZONE 'America/New_York';
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('19970710 173201 America/Does_not_exist');
|
|
|
|
SELECT '19970710 173201' AT TIME ZONE 'America/Does_not_exist';
|
|
|
|
|
2008-02-16 22:16:04 +01:00
|
|
|
-- Daylight saving time for timestamps beyond 32-bit time_t range.
|
|
|
|
SELECT '20500710 173201 Europe/Helsinki'::timestamptz; -- DST
|
|
|
|
SELECT '20500110 173201 Europe/Helsinki'::timestamptz; -- non-DST
|
|
|
|
|
|
|
|
SELECT '205000-07-10 17:32:01 Europe/Helsinki'::timestamptz; -- DST
|
|
|
|
SELECT '205000-01-10 17:32:01 Europe/Helsinki'::timestamptz; -- non-DST
|
|
|
|
|
2001-09-28 10:00:11 +02:00
|
|
|
-- Check date conversion and date arithmetic
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('1997-06-10 18:32:01 PDT');
|
|
|
|
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 10 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 11 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 12 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 13 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 14 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 15 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 1997');
|
|
|
|
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 0097 BC');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 0097');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 0597');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 1097');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 1697');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 1797');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 1897');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 2097');
|
|
|
|
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 28 17:32:01 1996');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 29 17:32:01 1996');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mar 01 17:32:01 1996');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Dec 30 17:32:01 1996');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Dec 31 17:32:01 1996');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Jan 01 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 28 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 29 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Mar 01 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Dec 30 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Dec 31 17:32:01 1997');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Dec 31 17:32:01 1999');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Jan 01 17:32:01 2000');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Dec 31 17:32:01 2000');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Jan 01 17:32:01 2001');
|
|
|
|
|
|
|
|
-- Currently unsupported syntax and ranges
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 -0097');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 5097 BC');
|
|
|
|
|
2007-11-07 13:24:24 +01:00
|
|
|
-- Alternative field order that we've historically supported (sort of)
|
2007-06-12 17:58:32 +02:00
|
|
|
-- with regular and POSIXy timezone specs
|
|
|
|
SELECT 'Wed Jul 11 10:51:14 America/New_York 2001'::timestamptz;
|
|
|
|
SELECT 'Wed Jul 11 10:51:14 GMT-4 2001'::timestamptz;
|
|
|
|
SELECT 'Wed Jul 11 10:51:14 GMT+4 2001'::timestamptz;
|
|
|
|
SELECT 'Wed Jul 11 10:51:14 PST-03:00 2001'::timestamptz;
|
|
|
|
SELECT 'Wed Jul 11 10:51:14 PST+03:00 2001'::timestamptz;
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT '' AS "64", d1 FROM TIMESTAMPTZ_TBL;
|
2001-09-28 10:00:11 +02:00
|
|
|
|
|
|
|
-- Demonstrate functions and operators
|
|
|
|
SELECT '' AS "48", d1 FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 > timestamp with time zone '1997-01-02';
|
|
|
|
|
|
|
|
SELECT '' AS "15", d1 FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 < timestamp with time zone '1997-01-02';
|
|
|
|
|
|
|
|
SELECT '' AS one, d1 FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 = timestamp with time zone '1997-01-02';
|
|
|
|
|
|
|
|
SELECT '' AS "63", d1 FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 != timestamp with time zone '1997-01-02';
|
|
|
|
|
|
|
|
SELECT '' AS "16", d1 FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 <= timestamp with time zone '1997-01-02';
|
|
|
|
|
|
|
|
SELECT '' AS "49", d1 FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 >= timestamp with time zone '1997-01-02';
|
|
|
|
|
|
|
|
SELECT '' AS "54", d1 - timestamp with time zone '1997-01-02' AS diff
|
|
|
|
FROM TIMESTAMPTZ_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
|
|
|
|
|
2004-03-05 03:41:14 +01:00
|
|
|
SELECT '' AS date_trunc_week, date_trunc( 'week', timestamp with time zone '2004-02-29 15:44:17.71393' ) AS week_trunc;
|
|
|
|
|
2001-09-28 10:00:11 +02:00
|
|
|
-- Test casting within a BETWEEN qualifier
|
|
|
|
SELECT '' AS "54", d1 - timestamp with time zone '1997-01-02' AS diff
|
|
|
|
FROM TIMESTAMPTZ_TBL
|
|
|
|
WHERE d1 BETWEEN timestamp with time zone '1902-01-01' AND timestamp with time zone '2038-01-01';
|
|
|
|
|
2001-10-03 07:29:27 +02:00
|
|
|
SELECT '' AS "54", d1 as timestamptz,
|
|
|
|
date_part( 'year', d1) AS year, date_part( 'month', d1) AS month,
|
2001-09-28 10:00:11 +02:00
|
|
|
date_part( 'day', d1) AS day, date_part( 'hour', d1) AS hour,
|
|
|
|
date_part( 'minute', d1) AS minute, date_part( 'second', d1) AS second
|
|
|
|
FROM TIMESTAMPTZ_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
|
|
|
|
|
2001-10-03 07:29:27 +02:00
|
|
|
SELECT '' AS "54", d1 as timestamptz,
|
|
|
|
date_part( 'quarter', d1) AS quarter, date_part( 'msec', d1) AS msec,
|
2001-09-28 10:00:11 +02:00
|
|
|
date_part( 'usec', d1) AS usec
|
|
|
|
FROM TIMESTAMPTZ_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
|
|
|
|
|
2007-02-17 02:51:42 +01:00
|
|
|
SELECT '' AS "54", d1 as timestamptz,
|
2007-02-16 18:49:15 +01:00
|
|
|
date_part( 'isoyear', d1) AS isoyear, date_part( 'week', d1) AS week,
|
|
|
|
date_part( 'dow', d1) AS dow
|
|
|
|
FROM TIMESTAMPTZ_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
|
|
|
|
|
2001-09-28 10:00:11 +02:00
|
|
|
-- TO_CHAR()
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon')
|
2001-09-28 10:00:11 +02:00
|
|
|
FROM TIMESTAMPTZ_TBL;
|
2010-11-23 21:27:50 +01:00
|
|
|
|
2001-09-28 10:00:11 +02:00
|
|
|
SELECT '' AS to_char_2, to_char(d1, 'FMDAY FMDay FMday FMMONTH FMMonth FMmonth FMRM')
|
2010-11-23 21:27:50 +01:00
|
|
|
FROM TIMESTAMPTZ_TBL;
|
2001-09-28 10:00:11 +02:00
|
|
|
|
|
|
|
SELECT '' AS to_char_3, to_char(d1, 'Y,YYY YYYY YYY YY Y CC Q MM WW DDD DD D J')
|
|
|
|
FROM TIMESTAMPTZ_TBL;
|
2010-11-23 21:27:50 +01:00
|
|
|
|
|
|
|
SELECT '' AS to_char_4, to_char(d1, 'FMY,YYY FMYYYY FMYYY FMYY FMY FMCC FMQ FMMM FMWW FMDDD FMDD FMD FMJ')
|
|
|
|
FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
SELECT '' AS to_char_5, to_char(d1, 'HH HH12 HH24 MI SS SSSS')
|
|
|
|
FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
SELECT '' AS to_char_6, to_char(d1, E'"HH:MI:SS is" HH:MI:SS "\\"text between quote marks\\""')
|
2001-09-28 10:00:11 +02:00
|
|
|
FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
SELECT '' AS to_char_7, to_char(d1, 'HH24--text--MI--text--SS')
|
2010-11-23 21:27:50 +01:00
|
|
|
FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
SELECT '' AS to_char_8, to_char(d1, 'YYYYTH YYYYth Jth')
|
|
|
|
FROM TIMESTAMPTZ_TBL;
|
2001-09-28 10:00:11 +02:00
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT '' AS to_char_9, to_char(d1, 'YYYY A.D. YYYY a.d. YYYY bc HH:MI:SS P.M. HH:MI:SS p.m. HH:MI:SS pm')
|
2001-09-28 10:00:11 +02:00
|
|
|
FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
2007-02-16 18:49:15 +01:00
|
|
|
SELECT '' AS to_char_10, to_char(d1, 'IYYY IYY IY I IW IDDD ID')
|
|
|
|
FROM TIMESTAMPTZ_TBL;
|
|
|
|
|
|
|
|
SELECT '' AS to_char_11, to_char(d1, 'FMIYYY FMIYY FMIY FMI FMIW FMIDDD FMID')
|
2007-02-16 16:42:42 +01:00
|
|
|
FROM TIMESTAMPTZ_TBL;
|
2013-10-16 19:22:55 +02:00
|
|
|
|
|
|
|
CREATE TABLE TIMESTAMPTZ_TST (a int , b timestamptz);
|
|
|
|
|
|
|
|
-- Test year field value with len > 4
|
|
|
|
INSERT INTO TIMESTAMPTZ_TST VALUES(1, 'Sat Mar 12 23:58:48 1000 IST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TST VALUES(2, 'Sat Mar 12 23:58:48 10000 IST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TST VALUES(3, 'Sat Mar 12 23:58:48 100000 IST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TST VALUES(3, '10000 Mar 12 23:58:48 IST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TST VALUES(4, '100000312 23:58:48 IST');
|
|
|
|
INSERT INTO TIMESTAMPTZ_TST VALUES(4, '1000000312 23:58:48 IST');
|
|
|
|
--Verify data
|
|
|
|
SELECT * FROM TIMESTAMPTZ_TST ORDER BY a;
|
|
|
|
--Cleanup
|
|
|
|
DROP TABLE TIMESTAMPTZ_TST;
|
2014-03-04 19:09:43 +01:00
|
|
|
|
|
|
|
-- test timestamptz constructors
|
|
|
|
set TimeZone to 'America/Santiago';
|
|
|
|
|
|
|
|
-- numeric timezone
|
|
|
|
SELECT make_timestamptz(1973, 07, 15, 08, 15, 55.33);
|
|
|
|
SELECT make_timestamptz(1973, 07, 15, 08, 15, 55.33, '+2');
|
|
|
|
SELECT make_timestamptz(1973, 07, 15, 08, 15, 55.33, '-2');
|
|
|
|
WITH tzs (tz) AS (VALUES
|
|
|
|
('+1'), ('+1:'), ('+1:0'), ('+100'), ('+1:00'), ('+01:00'),
|
|
|
|
('+10'), ('+1000'), ('+10:'), ('+10:0'), ('+10:00'), ('+10:00:'),
|
|
|
|
('+10:00:1'), ('+10:00:01'),
|
|
|
|
('+10:00:10'))
|
|
|
|
SELECT make_timestamptz(2010, 2, 27, 3, 45, 00, tz), tz FROM tzs;
|
|
|
|
|
|
|
|
-- these should fail
|
|
|
|
SELECT make_timestamptz(1973, 07, 15, 08, 15, 55.33, '2');
|
|
|
|
SELECT make_timestamptz(2014, 12, 10, 10, 10, 10, '+16');
|
|
|
|
SELECT make_timestamptz(2014, 12, 10, 10, 10, 10, '-16');
|
|
|
|
|
|
|
|
-- should be true
|
|
|
|
SELECT make_timestamptz(1973, 07, 15, 08, 15, 55.33, '+2') = '1973-07-15 08:15:55.33+02'::timestamptz;
|
|
|
|
|
2014-05-13 02:21:16 +02:00
|
|
|
-- full timezone names
|
2014-03-04 19:09:43 +01:00
|
|
|
SELECT make_timestamptz(2014, 12, 10, 0, 0, 0, 'Europe/Prague') = timestamptz '2014-12-10 00:00:00 Europe/Prague';
|
|
|
|
SELECT make_timestamptz(2014, 12, 10, 0, 0, 0, 'Europe/Prague') AT TIME ZONE 'UTC';
|
|
|
|
SELECT make_timestamptz(1846, 12, 10, 0, 0, 0, 'Asia/Manila') AT TIME ZONE 'UTC';
|
2014-05-13 02:21:16 +02:00
|
|
|
SELECT make_timestamptz(1881, 12, 10, 0, 0, 0, 'Europe/Paris') AT TIME ZONE 'UTC';
|
|
|
|
SELECT make_timestamptz(1910, 12, 24, 0, 0, 0, 'Nehwon/Lankhmar');
|
2014-03-04 19:09:43 +01:00
|
|
|
|
|
|
|
-- abbreviations
|
|
|
|
SELECT make_timestamptz(2008, 12, 10, 10, 10, 10, 'CLST');
|
|
|
|
SELECT make_timestamptz(2008, 12, 10, 10, 10, 10, 'CLT');
|
|
|
|
SELECT make_timestamptz(2014, 12, 10, 10, 10, 10, 'PST8PDT');
|
|
|
|
|
|
|
|
RESET TimeZone;
|
Support timezone abbreviations that sometimes change.
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
2014-10-16 21:22:10 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- Test behavior with a dynamic (time-varying) timezone abbreviation.
|
|
|
|
-- These tests rely on the knowledge that MSK (Europe/Moscow standard time)
|
2014-11-19 03:36:39 +01:00
|
|
|
-- moved forwards in Mar 2011 and that VET (America/Caracas standard time)
|
|
|
|
-- moved backwards in Dec 2007.
|
Support timezone abbreviations that sometimes change.
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
2014-10-16 21:22:10 +02:00
|
|
|
--
|
|
|
|
|
|
|
|
SET TimeZone to 'UTC';
|
|
|
|
|
|
|
|
SELECT '2011-03-27 00:00:00 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 01:00:00 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 01:59:59 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 02:00:00 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 02:00:01 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 02:59:59 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 03:00:00 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 03:00:01 Europe/Moscow'::timestamptz;
|
|
|
|
SELECT '2011-03-27 04:00:00 Europe/Moscow'::timestamptz;
|
|
|
|
|
|
|
|
SELECT '2011-03-27 00:00:00 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 01:00:00 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 01:59:59 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 02:00:00 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 02:00:01 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 02:59:59 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 03:00:00 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 03:00:01 MSK'::timestamptz;
|
|
|
|
SELECT '2011-03-27 04:00:00 MSK'::timestamptz;
|
|
|
|
|
2014-11-19 03:36:39 +01:00
|
|
|
SELECT '2007-12-09 02:00:00 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:29:59 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:30:00 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:30:01 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:59:59 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 03:00:00 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 03:00:01 America/Caracas'::timestamptz;
|
|
|
|
SELECT '2007-12-09 04:00:00 America/Caracas'::timestamptz;
|
|
|
|
|
|
|
|
SELECT '2007-12-09 02:00:00 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:29:59 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:30:00 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:30:01 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 02:59:59 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 03:00:00 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 03:00:01 VET'::timestamptz;
|
|
|
|
SELECT '2007-12-09 04:00:00 VET'::timestamptz;
|
Support timezone abbreviations that sometimes change.
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
2014-10-16 21:22:10 +02:00
|
|
|
|
|
|
|
SELECT '2011-03-27 00:00:00'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 01:00:00'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 01:59:59'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 02:00:00'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 02:00:01'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 02:59:59'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 03:00:00'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 03:00:01'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 04:00:00'::timestamp AT TIME ZONE 'Europe/Moscow';
|
|
|
|
|
|
|
|
SELECT '2011-03-27 00:00:00'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 01:00:00'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 01:59:59'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 02:00:00'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 02:00:01'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 02:59:59'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 03:00:00'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 03:00:01'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 04:00:00'::timestamp AT TIME ZONE 'MSK';
|
|
|
|
|
2014-11-19 03:36:39 +01:00
|
|
|
SELECT '2007-12-09 02:00:00'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 02:29:59'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 02:30:00'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 02:30:01'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 02:59:59'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 03:00:00'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 03:00:01'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 04:00:00'::timestamp AT TIME ZONE 'America/Caracas';
|
|
|
|
|
|
|
|
SELECT '2007-12-09 02:00:00'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 02:29:59'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 02:30:00'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 02:30:01'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 02:59:59'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 03:00:00'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 03:00:01'::timestamp AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 04:00:00'::timestamp AT TIME ZONE 'VET';
|
|
|
|
|
|
|
|
SELECT make_timestamptz(2007, 12, 9, 2, 0, 0, 'VET');
|
|
|
|
SELECT make_timestamptz(2007, 12, 9, 3, 0, 0, 'VET');
|
Support timezone abbreviations that sometimes change.
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
2014-10-16 21:22:10 +02:00
|
|
|
|
|
|
|
SET TimeZone to 'Europe/Moscow';
|
|
|
|
|
|
|
|
SELECT '2011-03-26 21:00:00 UTC'::timestamptz;
|
|
|
|
SELECT '2011-03-26 22:00:00 UTC'::timestamptz;
|
|
|
|
SELECT '2011-03-26 22:59:59 UTC'::timestamptz;
|
|
|
|
SELECT '2011-03-26 23:00:00 UTC'::timestamptz;
|
|
|
|
SELECT '2011-03-26 23:00:01 UTC'::timestamptz;
|
|
|
|
SELECT '2011-03-26 23:59:59 UTC'::timestamptz;
|
|
|
|
SELECT '2011-03-27 00:00:00 UTC'::timestamptz;
|
|
|
|
|
2014-11-19 03:36:39 +01:00
|
|
|
SET TimeZone to 'America/Caracas';
|
|
|
|
|
|
|
|
SELECT '2007-12-09 06:00:00 UTC'::timestamptz;
|
|
|
|
SELECT '2007-12-09 06:30:00 UTC'::timestamptz;
|
|
|
|
SELECT '2007-12-09 06:59:59 UTC'::timestamptz;
|
|
|
|
SELECT '2007-12-09 07:00:00 UTC'::timestamptz;
|
|
|
|
SELECT '2007-12-09 07:00:01 UTC'::timestamptz;
|
|
|
|
SELECT '2007-12-09 07:29:59 UTC'::timestamptz;
|
|
|
|
SELECT '2007-12-09 07:30:00 UTC'::timestamptz;
|
Support timezone abbreviations that sometimes change.
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
2014-10-16 21:22:10 +02:00
|
|
|
|
|
|
|
RESET TimeZone;
|
|
|
|
|
|
|
|
SELECT '2011-03-26 21:00:00 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-26 22:00:00 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-26 22:59:59 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-26 23:00:00 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-26 23:00:01 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-26 23:59:59 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
SELECT '2011-03-27 00:00:00 UTC'::timestamptz AT TIME ZONE 'Europe/Moscow';
|
|
|
|
|
2014-11-19 03:36:39 +01:00
|
|
|
SELECT '2007-12-09 06:00:00 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 06:30:00 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 06:59:59 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 07:00:00 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 07:00:01 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 07:29:59 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
|
|
|
SELECT '2007-12-09 07:30:00 UTC'::timestamptz AT TIME ZONE 'America/Caracas';
|
Support timezone abbreviations that sometimes change.
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
2014-10-16 21:22:10 +02:00
|
|
|
|
|
|
|
SELECT '2011-03-26 21:00:00 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-26 22:00:00 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-26 22:59:59 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-26 23:00:00 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-26 23:00:01 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-26 23:59:59 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
SELECT '2011-03-27 00:00:00 UTC'::timestamptz AT TIME ZONE 'MSK';
|
|
|
|
|
2014-11-19 03:36:39 +01:00
|
|
|
SELECT '2007-12-09 06:00:00 UTC'::timestamptz AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 06:30:00 UTC'::timestamptz AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 06:59:59 UTC'::timestamptz AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 07:00:00 UTC'::timestamptz AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 07:00:01 UTC'::timestamptz AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 07:29:59 UTC'::timestamptz AT TIME ZONE 'VET';
|
|
|
|
SELECT '2007-12-09 07:30:00 UTC'::timestamptz AT TIME ZONE 'VET';
|