rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/test/regress/expected/timestamptz.out

1404 lines
68 KiB
Plaintext
Raw Normal View History

Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
--
-- TIMESTAMPTZ
--
-- needed so tests pass even in Australia
SET australian_timezones = 'off';
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
CREATE TABLE TIMESTAMPTZ_TBL ( d1 timestamp(2) with time zone);
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('current');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: "current" is no longer supported
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
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';
one
-----
1
(1 row)
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'tomorrow';
one
-----
1
(1 row)
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'yesterday';
one
-----
1
(1 row)
SELECT count(*) AS None FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'now';
none
------
0
(1 row)
DELETE FROM TIMESTAMPTZ_TBL;
-- verify uniform transaction time within transaction block
BEGIN;
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('now');
Make regress tests safe for variable-resolution timestamps.
2001-10-04 16:51:06 +02:00
SELECT count(*) AS two FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp(2) with time zone 'now';
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
two
-----
2
(1 row)
END;
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');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: "invalid" is no longer supported
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
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');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Invalid Abstime');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: "Invalid Abstime" is no longer supported
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Undefined Abstime');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: "Undefined Abstime" is no longer supported
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
-- 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');
-- POSIX format
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');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 12:14:03 GMT -2');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 03:14:04 EST+3');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('2000-03-15 02:14:05 EST +2: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');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('97FEB10 5:32:01PM UTC');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('97/02/10 17:32:01 UTC');
INSERT INTO TIMESTAMPTZ_TBL VALUES ('97.041 17:32:01 UTC');
-- 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');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: invalid input syntax for timestamp with time zone: "Feb 29 17:32:01 1997"
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
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');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: invalid input syntax for timestamp with time zone: "Feb 16 17:32:01 -0097"
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
INSERT INTO TIMESTAMPTZ_TBL VALUES ('Feb 16 17:32:01 5097 BC');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: timestamp out of range: "Feb 16 17:32:01 5097 BC"
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
SELECT '' AS "64", d1 FROM TIMESTAMPTZ_TBL;
64 | d1
----+---------------------------------
| -infinity
| infinity
| Wed Dec 31 16:00:00 1969 PST
| Mon Feb 10 17:32:01 1997 PST
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:02 1997 PST
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Mon Feb 10 17:32:01.40 1997 PST
| Mon Feb 10 17:32:01.50 1997 PST
| Mon Feb 10 17:32:01.60 1997 PST
| Thu Jan 02 00:00:00 1997 PST
| Thu Jan 02 03:04:05 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Tue Jun 10 17:32:01 1997 PDT
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| Sat Sep 22 18:19:20 2001 PDT
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Wed Mar 15 08:14:01 2000 PST
| Wed Mar 15 04:14:02 2000 PST
| Wed Mar 15 02:14:03 2000 PST
| Wed Mar 15 03:14:04 2000 PST
| Wed Mar 15 01:14:05 2000 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:00 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Tue Jun 10 18:32:01 1997 PDT
| Mon Feb 10 17:32:01 1997 PST
| Tue Feb 11 17:32:01 1997 PST
| Wed Feb 12 17:32:01 1997 PST
| Thu Feb 13 17:32:01 1997 PST
| Fri Feb 14 17:32:01 1997 PST
| Sat Feb 15 17:32:01 1997 PST
| Sun Feb 16 17:32:01 1997 PST
Support alternate storage scheme of 64-bit integer for date/time types. Use "--enable-integer-datetimes" in configuration to use this rather than the original float8 storage. I would recommend the integer-based storage for any platform on which it is available. We perhaps should make this the default for the production release. Change timezone(timestamptz) results to return timestamp rather than a character string. Formerly, we didn't have a way to represent timestamps with an explicit time zone other than freezing the info into a string. Now, we can reasonably omit the explicit time zone from the result and return a timestamp with values appropriate for the specified time zone. Much cleaner, and if you need the time zone in the result you can put it into a character string pretty easily anyway. Allow fractional seconds in date/time types even for dates prior to 1BC. Limit timestamp data types to 6 decimal places of precision. Just right for a micro-second storage of int8 date/time types, and reduces the number of places ad-hoc rounding was occuring for the float8-based types. Use lookup tables for precision/rounding calculations for timestamp and interval types. Formerly used pow() to calculate the desired value but with a more limited range there is no reason to not type in a lookup table. Should be *much* better performance, though formerly there were some optimizations to help minimize the number of times pow() was called. Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option "--enable-integer-datetimes" and the existing internal INT64_IS_BUSTED. Add explicit date/interval operators and functions for addition and subtraction. Formerly relied on implicit type promotion from date to timestamp with time zone. Change timezone conversion functions for the timetz type from "timetz()" to "timezone()". This is consistant with other time zone coersion functions for other types. Bump the catalog version to 200204201. Fix up regression tests to reflect changes in fractional seconds representation for date/times in BC eras. All regression tests pass on my Linux box.
2002-04-21 21:52:18 +02:00
| Tue Feb 16 17:32:01 0097 BC
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Sat Feb 16 17:32:01 0097
| Thu Feb 16 17:32:01 0597
| Tue Feb 16 17:32:01 1097
| Sat Feb 16 17:32:01 1697
| Thu Feb 16 17:32:01 1797
| Tue Feb 16 17:32:01 1897
| Sun Feb 16 17:32:01 1997 PST
| Sat Feb 16 17:32:01 2097
| Wed Feb 28 17:32:01 1996 PST
| Thu Feb 29 17:32:01 1996 PST
| Fri Mar 01 17:32:01 1996 PST
| Mon Dec 30 17:32:01 1996 PST
| Tue Dec 31 17:32:01 1996 PST
| Wed Jan 01 17:32:01 1997 PST
| Fri Feb 28 17:32:01 1997 PST
| Sat Mar 01 17:32:01 1997 PST
| Tue Dec 30 17:32:01 1997 PST
| Wed Dec 31 17:32:01 1997 PST
| Fri Dec 31 17:32:01 1999 PST
| Sat Jan 01 17:32:01 2000 PST
| Sun Dec 31 17:32:01 2000 PST
| Mon Jan 01 17:32:01 2001 PST
(64 rows)
-- Demonstrate functions and operators
SELECT '' AS "48", d1 FROM TIMESTAMPTZ_TBL
WHERE d1 > timestamp with time zone '1997-01-02';
48 | d1
----+---------------------------------
| infinity
| Mon Feb 10 17:32:01 1997 PST
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:02 1997 PST
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Mon Feb 10 17:32:01.40 1997 PST
| Mon Feb 10 17:32:01.50 1997 PST
| Mon Feb 10 17:32:01.60 1997 PST
| Thu Jan 02 03:04:05 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Tue Jun 10 17:32:01 1997 PDT
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| Sat Sep 22 18:19:20 2001 PDT
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Wed Mar 15 08:14:01 2000 PST
| Wed Mar 15 04:14:02 2000 PST
| Wed Mar 15 02:14:03 2000 PST
| Wed Mar 15 03:14:04 2000 PST
| Wed Mar 15 01:14:05 2000 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:00 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Tue Jun 10 18:32:01 1997 PDT
| Mon Feb 10 17:32:01 1997 PST
| Tue Feb 11 17:32:01 1997 PST
| Wed Feb 12 17:32:01 1997 PST
| Thu Feb 13 17:32:01 1997 PST
| Fri Feb 14 17:32:01 1997 PST
| Sat Feb 15 17:32:01 1997 PST
| Sun Feb 16 17:32:01 1997 PST
| Sun Feb 16 17:32:01 1997 PST
| Sat Feb 16 17:32:01 2097
| Fri Feb 28 17:32:01 1997 PST
| Sat Mar 01 17:32:01 1997 PST
| Tue Dec 30 17:32:01 1997 PST
| Wed Dec 31 17:32:01 1997 PST
| Fri Dec 31 17:32:01 1999 PST
| Sat Jan 01 17:32:01 2000 PST
| Sun Dec 31 17:32:01 2000 PST
| Mon Jan 01 17:32:01 2001 PST
(48 rows)
SELECT '' AS "15", d1 FROM TIMESTAMPTZ_TBL
WHERE d1 < timestamp with time zone '1997-01-02';
15 | d1
----+------------------------------
| -infinity
| Wed Dec 31 16:00:00 1969 PST
Support alternate storage scheme of 64-bit integer for date/time types. Use "--enable-integer-datetimes" in configuration to use this rather than the original float8 storage. I would recommend the integer-based storage for any platform on which it is available. We perhaps should make this the default for the production release. Change timezone(timestamptz) results to return timestamp rather than a character string. Formerly, we didn't have a way to represent timestamps with an explicit time zone other than freezing the info into a string. Now, we can reasonably omit the explicit time zone from the result and return a timestamp with values appropriate for the specified time zone. Much cleaner, and if you need the time zone in the result you can put it into a character string pretty easily anyway. Allow fractional seconds in date/time types even for dates prior to 1BC. Limit timestamp data types to 6 decimal places of precision. Just right for a micro-second storage of int8 date/time types, and reduces the number of places ad-hoc rounding was occuring for the float8-based types. Use lookup tables for precision/rounding calculations for timestamp and interval types. Formerly used pow() to calculate the desired value but with a more limited range there is no reason to not type in a lookup table. Should be *much* better performance, though formerly there were some optimizations to help minimize the number of times pow() was called. Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option "--enable-integer-datetimes" and the existing internal INT64_IS_BUSTED. Add explicit date/interval operators and functions for addition and subtraction. Formerly relied on implicit type promotion from date to timestamp with time zone. Change timezone conversion functions for the timetz type from "timetz()" to "timezone()". This is consistant with other time zone coersion functions for other types. Bump the catalog version to 200204201. Fix up regression tests to reflect changes in fractional seconds representation for date/times in BC eras. All regression tests pass on my Linux box.
2002-04-21 21:52:18 +02:00
| Tue Feb 16 17:32:01 0097 BC
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Sat Feb 16 17:32:01 0097
| Thu Feb 16 17:32:01 0597
| Tue Feb 16 17:32:01 1097
| Sat Feb 16 17:32:01 1697
| Thu Feb 16 17:32:01 1797
| Tue Feb 16 17:32:01 1897
| Wed Feb 28 17:32:01 1996 PST
| Thu Feb 29 17:32:01 1996 PST
| Fri Mar 01 17:32:01 1996 PST
| Mon Dec 30 17:32:01 1996 PST
| Tue Dec 31 17:32:01 1996 PST
| Wed Jan 01 17:32:01 1997 PST
(15 rows)
SELECT '' AS one, d1 FROM TIMESTAMPTZ_TBL
WHERE d1 = timestamp with time zone '1997-01-02';
one | d1
-----+------------------------------
| Thu Jan 02 00:00:00 1997 PST
(1 row)
SELECT '' AS "63", d1 FROM TIMESTAMPTZ_TBL
WHERE d1 != timestamp with time zone '1997-01-02';
63 | d1
----+---------------------------------
| -infinity
| infinity
| Wed Dec 31 16:00:00 1969 PST
| Mon Feb 10 17:32:01 1997 PST
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:02 1997 PST
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Mon Feb 10 17:32:01.40 1997 PST
| Mon Feb 10 17:32:01.50 1997 PST
| Mon Feb 10 17:32:01.60 1997 PST
| Thu Jan 02 03:04:05 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Tue Jun 10 17:32:01 1997 PDT
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| Sat Sep 22 18:19:20 2001 PDT
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Wed Mar 15 08:14:01 2000 PST
| Wed Mar 15 04:14:02 2000 PST
| Wed Mar 15 02:14:03 2000 PST
| Wed Mar 15 03:14:04 2000 PST
| Wed Mar 15 01:14:05 2000 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:00 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Tue Jun 10 18:32:01 1997 PDT
| Mon Feb 10 17:32:01 1997 PST
| Tue Feb 11 17:32:01 1997 PST
| Wed Feb 12 17:32:01 1997 PST
| Thu Feb 13 17:32:01 1997 PST
| Fri Feb 14 17:32:01 1997 PST
| Sat Feb 15 17:32:01 1997 PST
| Sun Feb 16 17:32:01 1997 PST
Support alternate storage scheme of 64-bit integer for date/time types. Use "--enable-integer-datetimes" in configuration to use this rather than the original float8 storage. I would recommend the integer-based storage for any platform on which it is available. We perhaps should make this the default for the production release. Change timezone(timestamptz) results to return timestamp rather than a character string. Formerly, we didn't have a way to represent timestamps with an explicit time zone other than freezing the info into a string. Now, we can reasonably omit the explicit time zone from the result and return a timestamp with values appropriate for the specified time zone. Much cleaner, and if you need the time zone in the result you can put it into a character string pretty easily anyway. Allow fractional seconds in date/time types even for dates prior to 1BC. Limit timestamp data types to 6 decimal places of precision. Just right for a micro-second storage of int8 date/time types, and reduces the number of places ad-hoc rounding was occuring for the float8-based types. Use lookup tables for precision/rounding calculations for timestamp and interval types. Formerly used pow() to calculate the desired value but with a more limited range there is no reason to not type in a lookup table. Should be *much* better performance, though formerly there were some optimizations to help minimize the number of times pow() was called. Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option "--enable-integer-datetimes" and the existing internal INT64_IS_BUSTED. Add explicit date/interval operators and functions for addition and subtraction. Formerly relied on implicit type promotion from date to timestamp with time zone. Change timezone conversion functions for the timetz type from "timetz()" to "timezone()". This is consistant with other time zone coersion functions for other types. Bump the catalog version to 200204201. Fix up regression tests to reflect changes in fractional seconds representation for date/times in BC eras. All regression tests pass on my Linux box.
2002-04-21 21:52:18 +02:00
| Tue Feb 16 17:32:01 0097 BC
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Sat Feb 16 17:32:01 0097
| Thu Feb 16 17:32:01 0597
| Tue Feb 16 17:32:01 1097
| Sat Feb 16 17:32:01 1697
| Thu Feb 16 17:32:01 1797
| Tue Feb 16 17:32:01 1897
| Sun Feb 16 17:32:01 1997 PST
| Sat Feb 16 17:32:01 2097
| Wed Feb 28 17:32:01 1996 PST
| Thu Feb 29 17:32:01 1996 PST
| Fri Mar 01 17:32:01 1996 PST
| Mon Dec 30 17:32:01 1996 PST
| Tue Dec 31 17:32:01 1996 PST
| Wed Jan 01 17:32:01 1997 PST
| Fri Feb 28 17:32:01 1997 PST
| Sat Mar 01 17:32:01 1997 PST
| Tue Dec 30 17:32:01 1997 PST
| Wed Dec 31 17:32:01 1997 PST
| Fri Dec 31 17:32:01 1999 PST
| Sat Jan 01 17:32:01 2000 PST
| Sun Dec 31 17:32:01 2000 PST
| Mon Jan 01 17:32:01 2001 PST
(63 rows)
SELECT '' AS "16", d1 FROM TIMESTAMPTZ_TBL
WHERE d1 <= timestamp with time zone '1997-01-02';
16 | d1
----+------------------------------
| -infinity
| Wed Dec 31 16:00:00 1969 PST
| Thu Jan 02 00:00:00 1997 PST
Support alternate storage scheme of 64-bit integer for date/time types. Use "--enable-integer-datetimes" in configuration to use this rather than the original float8 storage. I would recommend the integer-based storage for any platform on which it is available. We perhaps should make this the default for the production release. Change timezone(timestamptz) results to return timestamp rather than a character string. Formerly, we didn't have a way to represent timestamps with an explicit time zone other than freezing the info into a string. Now, we can reasonably omit the explicit time zone from the result and return a timestamp with values appropriate for the specified time zone. Much cleaner, and if you need the time zone in the result you can put it into a character string pretty easily anyway. Allow fractional seconds in date/time types even for dates prior to 1BC. Limit timestamp data types to 6 decimal places of precision. Just right for a micro-second storage of int8 date/time types, and reduces the number of places ad-hoc rounding was occuring for the float8-based types. Use lookup tables for precision/rounding calculations for timestamp and interval types. Formerly used pow() to calculate the desired value but with a more limited range there is no reason to not type in a lookup table. Should be *much* better performance, though formerly there were some optimizations to help minimize the number of times pow() was called. Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option "--enable-integer-datetimes" and the existing internal INT64_IS_BUSTED. Add explicit date/interval operators and functions for addition and subtraction. Formerly relied on implicit type promotion from date to timestamp with time zone. Change timezone conversion functions for the timetz type from "timetz()" to "timezone()". This is consistant with other time zone coersion functions for other types. Bump the catalog version to 200204201. Fix up regression tests to reflect changes in fractional seconds representation for date/times in BC eras. All regression tests pass on my Linux box.
2002-04-21 21:52:18 +02:00
| Tue Feb 16 17:32:01 0097 BC
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Sat Feb 16 17:32:01 0097
| Thu Feb 16 17:32:01 0597
| Tue Feb 16 17:32:01 1097
| Sat Feb 16 17:32:01 1697
| Thu Feb 16 17:32:01 1797
| Tue Feb 16 17:32:01 1897
| Wed Feb 28 17:32:01 1996 PST
| Thu Feb 29 17:32:01 1996 PST
| Fri Mar 01 17:32:01 1996 PST
| Mon Dec 30 17:32:01 1996 PST
| Tue Dec 31 17:32:01 1996 PST
| Wed Jan 01 17:32:01 1997 PST
(16 rows)
SELECT '' AS "49", d1 FROM TIMESTAMPTZ_TBL
WHERE d1 >= timestamp with time zone '1997-01-02';
49 | d1
----+---------------------------------
| infinity
| Mon Feb 10 17:32:01 1997 PST
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:02 1997 PST
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Mon Feb 10 17:32:01.40 1997 PST
| Mon Feb 10 17:32:01.50 1997 PST
| Mon Feb 10 17:32:01.60 1997 PST
| Thu Jan 02 00:00:00 1997 PST
| Thu Jan 02 03:04:05 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Tue Jun 10 17:32:01 1997 PDT
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| Sat Sep 22 18:19:20 2001 PDT
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| Wed Mar 15 08:14:01 2000 PST
| Wed Mar 15 04:14:02 2000 PST
| Wed Mar 15 02:14:03 2000 PST
| Wed Mar 15 03:14:04 2000 PST
| Wed Mar 15 01:14:05 2000 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:00 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 17:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Mon Feb 10 09:32:01 1997 PST
| Tue Jun 10 18:32:01 1997 PDT
| Mon Feb 10 17:32:01 1997 PST
| Tue Feb 11 17:32:01 1997 PST
| Wed Feb 12 17:32:01 1997 PST
| Thu Feb 13 17:32:01 1997 PST
| Fri Feb 14 17:32:01 1997 PST
| Sat Feb 15 17:32:01 1997 PST
| Sun Feb 16 17:32:01 1997 PST
| Sun Feb 16 17:32:01 1997 PST
| Sat Feb 16 17:32:01 2097
| Fri Feb 28 17:32:01 1997 PST
| Sat Mar 01 17:32:01 1997 PST
| Tue Dec 30 17:32:01 1997 PST
| Wed Dec 31 17:32:01 1997 PST
| Fri Dec 31 17:32:01 1999 PST
| Sat Jan 01 17:32:01 2000 PST
| Sun Dec 31 17:32:01 2000 PST
| Mon Jan 01 17:32:01 2001 PST
(49 rows)
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';
54 | diff
----+----------------------------------------
| @ 9863 days 8 hours ago
| @ 39 days 17 hours 32 mins 1 sec
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 2 secs
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| @ 39 days 17 hours 32 mins 1.40 secs
| @ 39 days 17 hours 32 mins 1.50 secs
| @ 39 days 17 hours 32 mins 1.60 secs
| @ 0
| @ 3 hours 4 mins 5 secs
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 159 days 16 hours 32 mins 1 sec
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| @ 1724 days 17 hours 19 mins 20 secs
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| @ 1168 days 8 hours 14 mins 1 sec
| @ 1168 days 4 hours 14 mins 2 secs
| @ 1168 days 2 hours 14 mins 3 secs
| @ 1168 days 3 hours 14 mins 4 secs
| @ 1168 days 1 hour 14 mins 5 secs
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 9 hours 32 mins 1 sec
| @ 39 days 9 hours 32 mins 1 sec
| @ 39 days 9 hours 32 mins 1 sec
| @ 159 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 40 days 17 hours 32 mins 1 sec
| @ 41 days 17 hours 32 mins 1 sec
| @ 42 days 17 hours 32 mins 1 sec
| @ 43 days 17 hours 32 mins 1 sec
| @ 44 days 17 hours 32 mins 1 sec
| @ 45 days 17 hours 32 mins 1 sec
| @ 45 days 17 hours 32 mins 1 sec
| @ 308 days 6 hours 27 mins 59 secs ago
| @ 307 days 6 hours 27 mins 59 secs ago
| @ 306 days 6 hours 27 mins 59 secs ago
| @ 2 days 6 hours 27 mins 59 secs ago
| @ 1 day 6 hours 27 mins 59 secs ago
| @ 6 hours 27 mins 59 secs ago
| @ 57 days 17 hours 32 mins 1 sec
| @ 58 days 17 hours 32 mins 1 sec
| @ 362 days 17 hours 32 mins 1 sec
| @ 363 days 17 hours 32 mins 1 sec
| @ 1093 days 17 hours 32 mins 1 sec
| @ 1094 days 17 hours 32 mins 1 sec
| @ 1459 days 17 hours 32 mins 1 sec
| @ 1460 days 17 hours 32 mins 1 sec
(54 rows)
-- 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';
54 | diff
----+----------------------------------------
| @ 9863 days 8 hours ago
| @ 39 days 17 hours 32 mins 1 sec
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 2 secs
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| @ 39 days 17 hours 32 mins 1.40 secs
| @ 39 days 17 hours 32 mins 1.50 secs
| @ 39 days 17 hours 32 mins 1.60 secs
| @ 0
| @ 3 hours 4 mins 5 secs
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 159 days 16 hours 32 mins 1 sec
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| @ 1724 days 17 hours 19 mins 20 secs
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| @ 1168 days 8 hours 14 mins 1 sec
| @ 1168 days 4 hours 14 mins 2 secs
| @ 1168 days 2 hours 14 mins 3 secs
| @ 1168 days 3 hours 14 mins 4 secs
| @ 1168 days 1 hour 14 mins 5 secs
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 9 hours 32 mins 1 sec
| @ 39 days 9 hours 32 mins 1 sec
| @ 39 days 9 hours 32 mins 1 sec
| @ 159 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 40 days 17 hours 32 mins 1 sec
| @ 41 days 17 hours 32 mins 1 sec
| @ 42 days 17 hours 32 mins 1 sec
| @ 43 days 17 hours 32 mins 1 sec
| @ 44 days 17 hours 32 mins 1 sec
| @ 45 days 17 hours 32 mins 1 sec
| @ 45 days 17 hours 32 mins 1 sec
| @ 308 days 6 hours 27 mins 59 secs ago
| @ 307 days 6 hours 27 mins 59 secs ago
| @ 306 days 6 hours 27 mins 59 secs ago
| @ 2 days 6 hours 27 mins 59 secs ago
| @ 1 day 6 hours 27 mins 59 secs ago
| @ 6 hours 27 mins 59 secs ago
| @ 57 days 17 hours 32 mins 1 sec
| @ 58 days 17 hours 32 mins 1 sec
| @ 362 days 17 hours 32 mins 1 sec
| @ 363 days 17 hours 32 mins 1 sec
| @ 1093 days 17 hours 32 mins 1 sec
| @ 1094 days 17 hours 32 mins 1 sec
| @ 1459 days 17 hours 32 mins 1 sec
| @ 1460 days 17 hours 32 mins 1 sec
(54 rows)
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
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,
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
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';
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
54 | timestamptz | year | month | day | hour | minute | second
----+---------------------------------+------+-------+-----+------+--------+--------
| Wed Dec 31 16:00:00 1969 PST | 1969 | 12 | 31 | 16 | 0 | 0
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:02 1997 PST | 1997 | 2 | 10 | 17 | 32 | 2
| Mon Feb 10 17:32:01.40 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1.4
| Mon Feb 10 17:32:01.50 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1.5
| Mon Feb 10 17:32:01.60 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1.6
| Thu Jan 02 00:00:00 1997 PST | 1997 | 1 | 2 | 0 | 0 | 0
| Thu Jan 02 03:04:05 1997 PST | 1997 | 1 | 2 | 3 | 4 | 5
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Tue Jun 10 17:32:01 1997 PDT | 1997 | 6 | 10 | 17 | 32 | 1
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| Sat Sep 22 18:19:20 2001 PDT | 2001 | 9 | 22 | 18 | 19 | 20
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| Wed Mar 15 08:14:01 2000 PST | 2000 | 3 | 15 | 8 | 14 | 1
| Wed Mar 15 04:14:02 2000 PST | 2000 | 3 | 15 | 4 | 14 | 2
| Wed Mar 15 02:14:03 2000 PST | 2000 | 3 | 15 | 2 | 14 | 3
| Wed Mar 15 03:14:04 2000 PST | 2000 | 3 | 15 | 3 | 14 | 4
| Wed Mar 15 01:14:05 2000 PST | 2000 | 3 | 15 | 1 | 14 | 5
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:00 1997 PST | 1997 | 2 | 10 | 17 | 32 | 0
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 09:32:01 1997 PST | 1997 | 2 | 10 | 9 | 32 | 1
| Mon Feb 10 09:32:01 1997 PST | 1997 | 2 | 10 | 9 | 32 | 1
| Mon Feb 10 09:32:01 1997 PST | 1997 | 2 | 10 | 9 | 32 | 1
| Tue Jun 10 18:32:01 1997 PDT | 1997 | 6 | 10 | 18 | 32 | 1
| Mon Feb 10 17:32:01 1997 PST | 1997 | 2 | 10 | 17 | 32 | 1
| Tue Feb 11 17:32:01 1997 PST | 1997 | 2 | 11 | 17 | 32 | 1
| Wed Feb 12 17:32:01 1997 PST | 1997 | 2 | 12 | 17 | 32 | 1
| Thu Feb 13 17:32:01 1997 PST | 1997 | 2 | 13 | 17 | 32 | 1
| 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
| Sun Feb 16 17:32:01 1997 PST | 1997 | 2 | 16 | 17 | 32 | 1
| Wed Feb 28 17:32:01 1996 PST | 1996 | 2 | 28 | 17 | 32 | 1
| Thu Feb 29 17:32:01 1996 PST | 1996 | 2 | 29 | 17 | 32 | 1
| Fri Mar 01 17:32:01 1996 PST | 1996 | 3 | 1 | 17 | 32 | 1
| Mon Dec 30 17:32:01 1996 PST | 1996 | 12 | 30 | 17 | 32 | 1
| Tue Dec 31 17:32:01 1996 PST | 1996 | 12 | 31 | 17 | 32 | 1
| Wed Jan 01 17:32:01 1997 PST | 1997 | 1 | 1 | 17 | 32 | 1
| Fri Feb 28 17:32:01 1997 PST | 1997 | 2 | 28 | 17 | 32 | 1
| Sat Mar 01 17:32:01 1997 PST | 1997 | 3 | 1 | 17 | 32 | 1
| Tue Dec 30 17:32:01 1997 PST | 1997 | 12 | 30 | 17 | 32 | 1
| Wed Dec 31 17:32:01 1997 PST | 1997 | 12 | 31 | 17 | 32 | 1
| Fri Dec 31 17:32:01 1999 PST | 1999 | 12 | 31 | 17 | 32 | 1
| Sat Jan 01 17:32:01 2000 PST | 2000 | 1 | 1 | 17 | 32 | 1
| Sun Dec 31 17:32:01 2000 PST | 2000 | 12 | 31 | 17 | 32 | 1
| Mon Jan 01 17:32:01 2001 PST | 2001 | 1 | 1 | 17 | 32 | 1
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
(54 rows)
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
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,
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
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';
Fix bug in extract/date_part for milliseconds/miscroseconds and timestamp/timestamptz combo. Now extract/date_part returns seconds*1000 or 1000000 + fraction part as the manual stats. regression test are also fixed. See the thread in pgsql-hackers: Subject: Re: [HACKERS] timestamp_part() bug? Date: Sat, 02 Mar 2002 11:29:53 +0900
2002-03-04 04:55:50 +01:00
54 | timestamptz | quarter | msec | usec
----+---------------------------------+---------+-------+----------
| Wed Dec 31 16:00:00 1969 PST | 4 | 0 | 0
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:02 1997 PST | 1 | 2000 | 2000000
| Mon Feb 10 17:32:01.40 1997 PST | 1 | 1400 | 1400000
| Mon Feb 10 17:32:01.50 1997 PST | 1 | 1500 | 1500000
| Mon Feb 10 17:32:01.60 1997 PST | 1 | 1600 | 1600000
| Thu Jan 02 00:00:00 1997 PST | 1 | 0 | 0
| Thu Jan 02 03:04:05 1997 PST | 1 | 5000 | 5000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Tue Jun 10 17:32:01 1997 PDT | 2 | 1000 | 1000000
| Sat Sep 22 18:19:20 2001 PDT | 3 | 20000 | 20000000
| Wed Mar 15 08:14:01 2000 PST | 1 | 1000 | 1000000
| Wed Mar 15 04:14:02 2000 PST | 1 | 2000 | 2000000
| Wed Mar 15 02:14:03 2000 PST | 1 | 3000 | 3000000
| Wed Mar 15 03:14:04 2000 PST | 1 | 4000 | 4000000
| Wed Mar 15 01:14:05 2000 PST | 1 | 5000 | 5000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:00 1997 PST | 1 | 0 | 0
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 09:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 09:32:01 1997 PST | 1 | 1000 | 1000000
| Mon Feb 10 09:32:01 1997 PST | 1 | 1000 | 1000000
| Tue Jun 10 18:32:01 1997 PDT | 2 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 PST | 1 | 1000 | 1000000
| Tue Feb 11 17:32:01 1997 PST | 1 | 1000 | 1000000
| Wed Feb 12 17:32:01 1997 PST | 1 | 1000 | 1000000
| Thu Feb 13 17:32:01 1997 PST | 1 | 1000 | 1000000
| 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
| Sun Feb 16 17:32:01 1997 PST | 1 | 1000 | 1000000
| Wed Feb 28 17:32:01 1996 PST | 1 | 1000 | 1000000
| Thu Feb 29 17:32:01 1996 PST | 1 | 1000 | 1000000
| Fri Mar 01 17:32:01 1996 PST | 1 | 1000 | 1000000
| Mon Dec 30 17:32:01 1996 PST | 4 | 1000 | 1000000
| Tue Dec 31 17:32:01 1996 PST | 4 | 1000 | 1000000
| Wed Jan 01 17:32:01 1997 PST | 1 | 1000 | 1000000
| Fri Feb 28 17:32:01 1997 PST | 1 | 1000 | 1000000
| Sat Mar 01 17:32:01 1997 PST | 1 | 1000 | 1000000
| Tue Dec 30 17:32:01 1997 PST | 4 | 1000 | 1000000
| Wed Dec 31 17:32:01 1997 PST | 4 | 1000 | 1000000
| Fri Dec 31 17:32:01 1999 PST | 4 | 1000 | 1000000
| Sat Jan 01 17:32:01 2000 PST | 1 | 1000 | 1000000
| Sun Dec 31 17:32:01 2000 PST | 4 | 1000 | 1000000
| Mon Jan 01 17:32:01 2001 PST | 1 | 1000 | 1000000
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
(54 rows)
-- TO_CHAR()
SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon')
FROM TIMESTAMPTZ_TBL;
to_char_1 | to_char
-----------+------------------------------------------------------------------------------------------
|
|
| WEDNESDAY Wednesday wednesday WED Wed wed DECEMBER December december XII DEC Dec dec
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| THURSDAY Thursday thursday THU Thu thu JANUARY January january I JAN Jan jan
| THURSDAY Thursday thursday THU Thu thu JANUARY January january I JAN Jan jan
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| TUESDAY Tuesday tuesday TUE Tue tue JUNE June june VI JUN Jun jun
| SATURDAY Saturday saturday SAT Sat sat SEPTEMBER September september IX SEP Sep sep
| WEDNESDAY Wednesday wednesday WED Wed wed MARCH March march III MAR Mar mar
| WEDNESDAY Wednesday wednesday WED Wed wed MARCH March march III MAR Mar mar
| WEDNESDAY Wednesday wednesday WED Wed wed MARCH March march III MAR Mar mar
| WEDNESDAY Wednesday wednesday WED Wed wed MARCH March march III MAR Mar mar
| WEDNESDAY Wednesday wednesday WED Wed wed MARCH March march III MAR Mar mar
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| TUESDAY Tuesday tuesday TUE Tue tue JUNE June june VI JUN Jun jun
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
| TUESDAY Tuesday tuesday TUE Tue tue FEBRUARY February february II FEB Feb feb
| WEDNESDAY Wednesday wednesday WED Wed wed FEBRUARY February february II FEB Feb feb
| THURSDAY Thursday thursday THU Thu thu FEBRUARY February february II FEB Feb feb
| FRIDAY Friday friday FRI Fri fri FEBRUARY February february II FEB Feb feb
| SATURDAY Saturday saturday SAT Sat sat FEBRUARY February february II FEB Feb feb
| SUNDAY Sunday sunday SUN Sun sun FEBRUARY February february II FEB Feb feb
| TUESDAY Tuesday tuesday TUE Tue tue FEBRUARY February february II FEB Feb feb
| SATURDAY Saturday saturday SAT Sat sat FEBRUARY February february II FEB Feb feb
| THURSDAY Thursday thursday THU Thu thu FEBRUARY February february II FEB Feb feb
| TUESDAY Tuesday tuesday TUE Tue tue FEBRUARY February february II FEB Feb feb
| SATURDAY Saturday saturday SAT Sat sat FEBRUARY February february II FEB Feb feb
| THURSDAY Thursday thursday THU Thu thu FEBRUARY February february II FEB Feb feb
| TUESDAY Tuesday tuesday TUE Tue tue FEBRUARY February february II FEB Feb feb
| SUNDAY Sunday sunday SUN Sun sun FEBRUARY February february II FEB Feb feb
| SATURDAY Saturday saturday SAT Sat sat FEBRUARY February february II FEB Feb feb
| WEDNESDAY Wednesday wednesday WED Wed wed FEBRUARY February february II FEB Feb feb
| THURSDAY Thursday thursday THU Thu thu FEBRUARY February february II FEB Feb feb
| FRIDAY Friday friday FRI Fri fri MARCH March march III MAR Mar mar
| MONDAY Monday monday MON Mon mon DECEMBER December december XII DEC Dec dec
| TUESDAY Tuesday tuesday TUE Tue tue DECEMBER December december XII DEC Dec dec
| WEDNESDAY Wednesday wednesday WED Wed wed JANUARY January january I JAN Jan jan
| FRIDAY Friday friday FRI Fri fri FEBRUARY February february II FEB Feb feb
| SATURDAY Saturday saturday SAT Sat sat MARCH March march III MAR Mar mar
| TUESDAY Tuesday tuesday TUE Tue tue DECEMBER December december XII DEC Dec dec
| WEDNESDAY Wednesday wednesday WED Wed wed DECEMBER December december XII DEC Dec dec
| FRIDAY Friday friday FRI Fri fri DECEMBER December december XII DEC Dec dec
| SATURDAY Saturday saturday SAT Sat sat JANUARY January january I JAN Jan jan
| SUNDAY Sunday sunday SUN Sun sun DECEMBER December december XII DEC Dec dec
| MONDAY Monday monday MON Mon mon JANUARY January january I JAN Jan jan
(64 rows)
SELECT '' AS to_char_2, to_char(d1, 'FMDAY FMDay FMday FMMONTH FMMonth FMmonth FMRM')
FROM TIMESTAMPTZ_TBL;
to_char_2 | to_char
-----------+--------------------------------------------------------------
|
|
| WEDNESDAY Wednesday wednesday DECEMBER December december XII
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| THURSDAY Thursday thursday JANUARY January january I
| THURSDAY Thursday thursday JANUARY January january I
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| TUESDAY Tuesday tuesday JUNE June june VI
| SATURDAY Saturday saturday SEPTEMBER September september IX
| WEDNESDAY Wednesday wednesday MARCH March march III
| WEDNESDAY Wednesday wednesday MARCH March march III
| WEDNESDAY Wednesday wednesday MARCH March march III
| WEDNESDAY Wednesday wednesday MARCH March march III
| WEDNESDAY Wednesday wednesday MARCH March march III
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| MONDAY Monday monday FEBRUARY February february II
| TUESDAY Tuesday tuesday JUNE June june VI
| MONDAY Monday monday FEBRUARY February february II
| TUESDAY Tuesday tuesday FEBRUARY February february II
| WEDNESDAY Wednesday wednesday FEBRUARY February february II
| THURSDAY Thursday thursday FEBRUARY February february II
| FRIDAY Friday friday FEBRUARY February february II
| SATURDAY Saturday saturday FEBRUARY February february II
| SUNDAY Sunday sunday FEBRUARY February february II
| TUESDAY Tuesday tuesday FEBRUARY February february II
| SATURDAY Saturday saturday FEBRUARY February february II
| THURSDAY Thursday thursday FEBRUARY February february II
| TUESDAY Tuesday tuesday FEBRUARY February february II
| SATURDAY Saturday saturday FEBRUARY February february II
| THURSDAY Thursday thursday FEBRUARY February february II
| TUESDAY Tuesday tuesday FEBRUARY February february II
| SUNDAY Sunday sunday FEBRUARY February february II
| SATURDAY Saturday saturday FEBRUARY February february II
| WEDNESDAY Wednesday wednesday FEBRUARY February february II
| THURSDAY Thursday thursday FEBRUARY February february II
| FRIDAY Friday friday MARCH March march III
| MONDAY Monday monday DECEMBER December december XII
| TUESDAY Tuesday tuesday DECEMBER December december XII
| WEDNESDAY Wednesday wednesday JANUARY January january I
| FRIDAY Friday friday FEBRUARY February february II
| SATURDAY Saturday saturday MARCH March march III
| TUESDAY Tuesday tuesday DECEMBER December december XII
| WEDNESDAY Wednesday wednesday DECEMBER December december XII
| FRIDAY Friday friday DECEMBER December december XII
| SATURDAY Saturday saturday JANUARY January january I
| SUNDAY Sunday sunday DECEMBER December december XII
| MONDAY Monday monday JANUARY January january I
(64 rows)
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;
to_char_3 | to_char
-----------+-------------------------------------------------
|
|
| 1,969 1969 969 69 9 20 4 12 53 365 31 4 2440587
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 01 01 002 02 5 2450451
| 1,997 1997 997 97 7 20 1 01 01 002 02 5 2450451
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 2 06 23 161 10 3 2450610
| 2,001 2001 001 01 1 21 3 09 38 265 22 7 2452175
| 2,000 2000 000 00 0 21 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 21 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 21 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 21 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 21 1 03 11 075 15 4 2451619
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 2 06 23 161 10 3 2450610
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
| 1,997 1997 997 97 7 20 1 02 06 042 11 3 2450491
| 1,997 1997 997 97 7 20 1 02 07 043 12 4 2450492
| 1,997 1997 997 97 7 20 1 02 07 044 13 5 2450493
| 1,997 1997 997 97 7 20 1 02 07 045 14 6 2450494
| 1,997 1997 997 97 7 20 1 02 07 046 15 7 2450495
| 1,997 1997 997 97 7 20 1 02 07 047 16 1 2450496
| 0,097 0097 097 97 7 01 1 02 07 047 16 3 1686042
| 0,097 0097 097 97 7 01 1 02 07 047 16 7 1756536
| 0,597 0597 597 97 7 06 1 02 07 047 16 5 1939157
| 1,097 1097 097 97 7 11 1 02 07 047 16 3 2121778
| 1,697 1697 697 97 7 17 1 02 07 047 16 7 2340924
| 1,797 1797 797 97 7 18 1 02 07 047 16 5 2377448
| 1,897 1897 897 97 7 19 1 02 07 047 16 3 2413972
| 1,997 1997 997 97 7 20 1 02 07 047 16 1 2450496
| 2,097 2097 097 97 7 21 1 02 07 047 16 7 2487021
| 1,996 1996 996 96 6 20 1 02 09 059 28 4 2450142
| 1,996 1996 996 96 6 20 1 02 09 060 29 5 2450143
| 1,996 1996 996 96 6 20 1 03 09 061 01 6 2450144
| 1,996 1996 996 96 6 20 4 12 53 365 30 2 2450448
| 1,996 1996 996 96 6 20 4 12 53 366 31 3 2450449
| 1,997 1997 997 97 7 20 1 01 01 001 01 4 2450450
| 1,997 1997 997 97 7 20 1 02 09 059 28 6 2450508
| 1,997 1997 997 97 7 20 1 03 09 060 01 7 2450509
| 1,997 1997 997 97 7 20 4 12 52 364 30 3 2450813
| 1,997 1997 997 97 7 20 4 12 53 365 31 4 2450814
| 1,999 1999 999 99 9 20 4 12 53 365 31 6 2451544
| 2,000 2000 000 00 0 21 1 01 01 001 01 7 2451545
| 2,000 2000 000 00 0 21 4 12 53 366 31 1 2451910
| 2,001 2001 001 01 1 21 1 01 01 001 01 2 2451911
(64 rows)
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;
to_char_4 | to_char
-----------+-------------------------------------------------
|
|
| 1,969 1969 969 69 9 20 4 12 53 365 31 4 2440587
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 1 1 2 2 5 2450451
| 1,997 1997 997 97 7 20 1 1 1 2 2 5 2450451
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 2 6 23 161 10 3 2450610
| 2,001 2001 001 01 1 21 3 9 38 265 22 7 2452175
| 2,000 2000 000 00 0 21 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 21 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 21 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 21 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 21 1 3 11 75 15 4 2451619
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 2 6 23 161 10 3 2450610
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
| 1,997 1997 997 97 7 20 1 2 6 42 11 3 2450491
| 1,997 1997 997 97 7 20 1 2 7 43 12 4 2450492
| 1,997 1997 997 97 7 20 1 2 7 44 13 5 2450493
| 1,997 1997 997 97 7 20 1 2 7 45 14 6 2450494
| 1,997 1997 997 97 7 20 1 2 7 46 15 7 2450495
| 1,997 1997 997 97 7 20 1 2 7 47 16 1 2450496
| 0,097 97 097 97 7 1 1 2 7 47 16 3 1686042
| 0,097 97 097 97 7 1 1 2 7 47 16 7 1756536
| 0,597 597 597 97 7 6 1 2 7 47 16 5 1939157
| 1,097 1097 097 97 7 11 1 2 7 47 16 3 2121778
| 1,697 1697 697 97 7 17 1 2 7 47 16 7 2340924
| 1,797 1797 797 97 7 18 1 2 7 47 16 5 2377448
| 1,897 1897 897 97 7 19 1 2 7 47 16 3 2413972
| 1,997 1997 997 97 7 20 1 2 7 47 16 1 2450496
| 2,097 2097 097 97 7 21 1 2 7 47 16 7 2487021
| 1,996 1996 996 96 6 20 1 2 9 59 28 4 2450142
| 1,996 1996 996 96 6 20 1 2 9 60 29 5 2450143
| 1,996 1996 996 96 6 20 1 3 9 61 1 6 2450144
| 1,996 1996 996 96 6 20 4 12 53 365 30 2 2450448
| 1,996 1996 996 96 6 20 4 12 53 366 31 3 2450449
| 1,997 1997 997 97 7 20 1 1 1 1 1 4 2450450
| 1,997 1997 997 97 7 20 1 2 9 59 28 6 2450508
| 1,997 1997 997 97 7 20 1 3 9 60 1 7 2450509
| 1,997 1997 997 97 7 20 4 12 52 364 30 3 2450813
| 1,997 1997 997 97 7 20 4 12 53 365 31 4 2450814
| 1,999 1999 999 99 9 20 4 12 53 365 31 6 2451544
| 2,000 2000 000 00 0 21 1 1 1 1 1 7 2451545
| 2,000 2000 000 00 0 21 4 12 53 366 31 1 2451910
| 2,001 2001 001 01 1 21 1 1 1 1 1 2 2451911
(64 rows)
SELECT '' AS to_char_5, to_char(d1, 'HH HH12 HH24 MI SS SSSS')
FROM TIMESTAMPTZ_TBL;
to_char_5 | to_char
-----------+----------------------
|
|
| 04 04 16 00 00 57600
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| 05 05 17 32 02 63122
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 12 12 00 00 00 0
| 03 03 03 04 05 11045
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| 06 06 18 19 20 65960
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| 08 08 08 14 01 29641
| 04 04 04 14 02 15242
| 02 02 02 14 03 8043
| 03 03 03 14 04 11644
| 01 01 01 14 05 4445
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 00 63120
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 09 09 09 32 01 34321
| 09 09 09 32 01 34321
| 09 09 09 32 01 34321
| 06 06 18 32 01 66721
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
| 05 05 17 32 01 63121
(64 rows)
SELECT '' AS to_char_6, to_char(d1, '"HH:MI:SS is" HH:MI:SS "\\"text between quote marks\\""')
FROM TIMESTAMPTZ_TBL;
to_char_6 | to_char
-----------+-------------------------------------------------
|
|
| HH:MI:SS is 04:00:00 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| HH:MI:SS is 05:32:02 "text between quote marks"
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 12:00:00 "text between quote marks"
| HH:MI:SS is 03:04:05 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| HH:MI:SS is 06:19:20 "text between quote marks"
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| HH:MI:SS is 08:14:01 "text between quote marks"
| HH:MI:SS is 04:14:02 "text between quote marks"
| HH:MI:SS is 02:14:03 "text between quote marks"
| HH:MI:SS is 03:14:04 "text between quote marks"
| HH:MI:SS is 01:14:05 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:00 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 09:32:01 "text between quote marks"
| HH:MI:SS is 09:32:01 "text between quote marks"
| HH:MI:SS is 09:32:01 "text between quote marks"
| HH:MI:SS is 06:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
| HH:MI:SS is 05:32:01 "text between quote marks"
(64 rows)
SELECT '' AS to_char_7, to_char(d1, 'HH24--text--MI--text--SS')
FROM TIMESTAMPTZ_TBL;
to_char_7 | to_char
-----------+------------------------
|
|
| 16--text--00--text--00
| 17--text--32--text--01
| 17--text--32--text--01
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| 17--text--32--text--02
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 00--text--00--text--00
| 03--text--04--text--05
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| 18--text--19--text--20
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| 08--text--14--text--01
| 04--text--14--text--02
| 02--text--14--text--03
| 03--text--14--text--04
| 01--text--14--text--05
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--00
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 09--text--32--text--01
| 09--text--32--text--01
| 09--text--32--text--01
| 18--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
| 17--text--32--text--01
(64 rows)
SELECT '' AS to_char_8, to_char(d1, 'YYYYTH YYYYth Jth')
FROM TIMESTAMPTZ_TBL;
to_char_8 | to_char
-----------+-------------------------
|
|
| 1969TH 1969th 2440587th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450451st
| 1997TH 1997th 2450451st
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450610th
| 2001ST 2001st 2452175th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450610th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450491st
| 1997TH 1997th 2450492nd
| 1997TH 1997th 2450493rd
| 1997TH 1997th 2450494th
| 1997TH 1997th 2450495th
| 1997TH 1997th 2450496th
| 0097TH 0097th 1686042nd
| 0097TH 0097th 1756536th
| 0597TH 0597th 1939157th
| 1097TH 1097th 2121778th
| 1697TH 1697th 2340924th
| 1797TH 1797th 2377448th
| 1897TH 1897th 2413972nd
| 1997TH 1997th 2450496th
| 2097TH 2097th 2487021st
| 1996TH 1996th 2450142nd
| 1996TH 1996th 2450143rd
| 1996TH 1996th 2450144th
| 1996TH 1996th 2450448th
| 1996TH 1996th 2450449th
| 1997TH 1997th 2450450th
| 1997TH 1997th 2450508th
| 1997TH 1997th 2450509th
| 1997TH 1997th 2450813th
| 1997TH 1997th 2450814th
| 1999TH 1999th 2451544th
| 2000TH 2000th 2451545th
| 2000TH 2000th 2451910th
| 2001ST 2001st 2451911th
(64 rows)
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')
FROM TIMESTAMPTZ_TBL;
to_char_9 | to_char
-----------+---------------------------------------------------------------------
|
|
| 1969 A.D. 1969 a.d. 1969 ad 04:00:00 P.M. 04:00:00 p.m. 04:00:00 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
Implement precision support for timestamp and time, both with and without time zones. SQL99 spec requires a default of zero (round to seconds) which is set in gram.y as typmod is set in the parse tree. We *could* change to a default of either 6 (for internal compatibility with previous versions) or 2 (for external compatibility with previous versions). Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and other date/time types. Try to recognize cases where side effects like the current time zone setting may have an effect on results to decide whether something is cachable or not.
2001-10-03 07:29:27 +02:00
| 1997 A.D. 1997 a.d. 1997 ad 05:32:02 P.M. 05:32:02 p.m. 05:32:02 pm
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 12:00:00 A.M. 12:00:00 a.m. 12:00:00 am
| 1997 A.D. 1997 a.d. 1997 ad 03:04:05 A.M. 03:04:05 a.m. 03:04:05 am
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
Fix transposed arguments for typmod for one INTERVAL production. Mask both typmod subfields for INTERVAL to avoid setting the high bit, per dire warning from Tom Lane. Clear tmask for DTK_ISO_TIME case to avoid time zone troubles. Symptom reported by Tom Lane. Clean up checking for valid time zone info in output routine. This should now work for both SQL99 and Unix-style time zones. Put in explicit check for INTERVAL() typmod rounding to avoid accumulating cruft in the lower bits. Not sure that this helps, but we'll need to do something. The symptom is visible with a query like select interval(2) '10000 days 01:02:03.040506'; Regression tests are patched to repair the Tom Lane symptom, and all pass.
2001-10-20 03:02:22 +02:00
| 2001 A.D. 2001 a.d. 2001 ad 06:19:20 P.M. 06:19:20 p.m. 06:19:20 pm
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
| 2000 A.D. 2000 a.d. 2000 ad 08:14:01 A.M. 08:14:01 a.m. 08:14:01 am
| 2000 A.D. 2000 a.d. 2000 ad 04:14:02 A.M. 04:14:02 a.m. 04:14:02 am
| 2000 A.D. 2000 a.d. 2000 ad 02:14:03 A.M. 02:14:03 a.m. 02:14:03 am
| 2000 A.D. 2000 a.d. 2000 ad 03:14:04 A.M. 03:14:04 a.m. 03:14:04 am
| 2000 A.D. 2000 a.d. 2000 ad 01:14:05 A.M. 01:14:05 a.m. 01:14:05 am
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:00 P.M. 05:32:00 p.m. 05:32:00 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 09:32:01 A.M. 09:32:01 a.m. 09:32:01 am
| 1997 A.D. 1997 a.d. 1997 ad 09:32:01 A.M. 09:32:01 a.m. 09:32:01 am
| 1997 A.D. 1997 a.d. 1997 ad 09:32:01 A.M. 09:32:01 a.m. 09:32:01 am
| 1997 A.D. 1997 a.d. 1997 ad 06:32:01 P.M. 06:32:01 p.m. 06:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 0097 B.C. 0097 b.c. 0097 bc 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 0097 A.D. 0097 a.d. 0097 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 0597 A.D. 0597 a.d. 0597 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1097 A.D. 1097 a.d. 1097 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1697 A.D. 1697 a.d. 1697 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1797 A.D. 1797 a.d. 1797 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1897 A.D. 1897 a.d. 1897 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 2097 A.D. 2097 a.d. 2097 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1996 A.D. 1996 a.d. 1996 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1996 A.D. 1996 a.d. 1996 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1996 A.D. 1996 a.d. 1996 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1996 A.D. 1996 a.d. 1996 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1996 A.D. 1996 a.d. 1996 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 1999 A.D. 1999 a.d. 1999 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 2000 A.D. 2000 a.d. 2000 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 2000 A.D. 2000 a.d. 2000 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
| 2001 A.D. 2001 a.d. 2001 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
(64 rows)
-- TO_TIMESTAMP()
SELECT '' AS to_timestamp_1, to_timestamp('0097/Feb/16 --> 08:14:30', 'YYYY/Mon/DD --> HH:MI:SS');
to_timestamp_1 | to_timestamp
----------------+--------------------------
| Sat Feb 16 08:14:30 0097
(1 row)
SELECT '' AS to_timestamp_2, to_timestamp('97/2/16 8:14:30', 'FMYYYY/FMMM/FMDD FMHH:FMMI:FMSS');
to_timestamp_2 | to_timestamp
----------------+--------------------------
| Sat Feb 16 08:14:30 0097
(1 row)
SELECT '' AS to_timestamp_3, to_timestamp('1985 January 12', 'YYYY FMMonth DD');
to_timestamp_3 | to_timestamp
----------------+------------------------------
| Sat Jan 12 00:00:00 1985 PST
(1 row)
SELECT '' AS to_timestamp_4, to_timestamp('My birthday-> Year: 1976, Month: May, Day: 16',
'"My birthday-> Year" YYYY, "Month:" FMMonth, "Day:" DD');
to_timestamp_4 | to_timestamp
----------------+------------------------------
| Sun May 16 00:00:00 1976 PDT
(1 row)
SELECT '' AS to_timestamp_5, to_timestamp('1,582nd VIII 21', 'Y,YYYth FMRM DD');
to_timestamp_5 | to_timestamp
----------------+--------------------------
| Sat Aug 21 00:00:00 1582
(1 row)
SELECT '' AS to_timestamp_6, to_timestamp('15 "text between quote marks" 98 54 45',
'HH "\\text between quote marks\\"" YY MI SS');
to_timestamp_6 | to_timestamp
----------------+------------------------------
| Thu Jan 01 15:54:45 1998 PST
(1 row)
SELECT '' AS to_timestamp_7, to_timestamp('05121445482000', 'MMDDHHMISSYYYY');
to_timestamp_7 | to_timestamp
----------------+------------------------------
| Fri May 12 14:45:48 2000 PDT
(1 row)
SELECT '' AS to_timestamp_8, to_timestamp('2000January09Sunday', 'YYYYFMMonthDDFMDay');
to_timestamp_8 | to_timestamp
----------------+------------------------------
| Sun Jan 09 00:00:00 2000 PST
(1 row)
SELECT '' AS to_timestamp_9, to_timestamp('97/Feb/16', 'YYMonDD');
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ERROR: invalid value for MON/Mon/mon
Add separate regression tests for timetz and the new timestamptz type. Modify the timestamp test to reflect the "no time zone" behavior of this new code; timestamptz resembles the old timestamp code.
2001-09-28 10:00:11 +02:00
SELECT '' AS to_timestamp_10, to_timestamp('19971116', 'YYYYMMDD');
to_timestamp_10 | to_timestamp
-----------------+------------------------------
| Sun Nov 16 00:00:00 1997 PST
(1 row)
SELECT '' AS to_timestamp_11, to_timestamp('20000-1116', 'YYYY-MMDD');
to_timestamp_11 | to_timestamp
-----------------+---------------------------
| Thu Nov 16 00:00:00 20000
(1 row)
SELECT '' AS to_timestamp_12, to_timestamp('9-1116', 'Y-MMDD');
to_timestamp_12 | to_timestamp
-----------------+------------------------------
| Mon Nov 16 00:00:00 2009 PST
(1 row)
SELECT '' AS to_timestamp_13, to_timestamp('95-1116', 'YY-MMDD');
to_timestamp_13 | to_timestamp
-----------------+------------------------------
| Thu Nov 16 00:00:00 1995 PST
(1 row)
SELECT '' AS to_timestamp_14, to_timestamp('995-1116', 'YYY-MMDD');
to_timestamp_14 | to_timestamp
-----------------+------------------------------
| Thu Nov 16 00:00:00 1995 PST
(1 row)
SET DateStyle TO DEFAULT;