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/timestamp.out

1679 lines
78 KiB
Plaintext
Raw Normal View History

Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
--
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
-- TIMESTAMP
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
--
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 TIMESTAMP_TBL ( d1 timestamp(2) without time zone);
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Shorthand values
-- Not directly usable for regression testing since these are not constants.
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
-- So, just try to test parser and hope for the best - thomas 97/04/26
Make regress tests safe for variable-resolution timestamps.
2001-10-04 16:51:06 +02:00
-- NB: could get a failure if local midnight passes during the next few
-- statements.
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 TIMESTAMP_TBL VALUES ('now');
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('current');
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
ERROR: date/time value "current" is no longer supported
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('today');
INSERT INTO TIMESTAMP_TBL VALUES ('yesterday');
INSERT INTO TIMESTAMP_TBL VALUES ('tomorrow');
INSERT INTO TIMESTAMP_TBL VALUES ('tomorrow EST');
INSERT INTO TIMESTAMP_TBL VALUES ('tomorrow zulu');
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 count(*) AS One FROM TIMESTAMP_TBL WHERE d1 = timestamp without time zone 'today';
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
one
-----
1
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(1 row)
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 count(*) AS One FROM TIMESTAMP_TBL WHERE d1 = timestamp without time zone 'tomorrow';
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
one
-----
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
3
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(1 row)
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 count(*) AS One FROM TIMESTAMP_TBL WHERE d1 = timestamp without time zone 'yesterday';
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
one
-----
1
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(1 row)
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 count(*) AS None FROM TIMESTAMP_TBL WHERE d1 = timestamp without time zone 'now';
none
------
0
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(1 row)
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
DELETE FROM TIMESTAMP_TBL;
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- verify uniform transaction time within transaction block
BEGIN;
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('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
INSERT INTO TIMESTAMP_TBL VALUES ('now');
Make regress tests safe for variable-resolution timestamps.
2001-10-04 16:51:06 +02:00
SELECT count(*) AS two FROM TIMESTAMP_TBL WHERE d1 = timestamp(2) without time zone 'now';
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
two
-----
2
Test for "current" time by comparing against "now".
1997-09-01 08:16:08 +02:00
(1 row)
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
END;
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
DELETE FROM TIMESTAMP_TBL;
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Special values
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('-infinity');
INSERT INTO TIMESTAMP_TBL VALUES ('infinity');
INSERT INTO TIMESTAMP_TBL VALUES ('epoch');
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
-- Obsolete special values
INSERT INTO TIMESTAMP_TBL VALUES ('invalid');
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
ERROR: date/time value "invalid" is no longer supported
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Postgres v6.0 standard output format
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('Mon Feb 10 17:32:01 1997 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('Invalid Abstime');
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
ERROR: date/time value "Invalid Abstime" is no longer supported
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('Undefined Abstime');
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
ERROR: date/time value "Undefined Abstime" is no longer supported
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Variations on Postgres v6.1 standard output format
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('Mon Feb 10 17:32:01.000001 1997 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('Mon Feb 10 17:32:01.999999 1997 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('Mon Feb 10 17:32:01.4 1997 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('Mon Feb 10 17:32:01.5 1997 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('Mon Feb 10 17:32:01.6 1997 PST');
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- ISO 8601 format
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('1997-01-02');
INSERT INTO TIMESTAMP_TBL VALUES ('1997-01-02 03:04:05');
INSERT INTO TIMESTAMP_TBL VALUES ('1997-02-10 17:32:01-08');
INSERT INTO TIMESTAMP_TBL VALUES ('1997-02-10 17:32:01-0800');
INSERT INTO TIMESTAMP_TBL VALUES ('1997-02-10 17:32:01 -08:00');
INSERT INTO TIMESTAMP_TBL VALUES ('19970210 173201 -0800');
INSERT INTO TIMESTAMP_TBL VALUES ('1997-06-10 17:32:01 -07:00');
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 TIMESTAMP_TBL VALUES ('2001-09-22T18:19:20');
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
-- POSIX format (note that the timezone abbrev is just decoration here)
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('2000-03-15 08:14:01 GMT+8');
INSERT INTO TIMESTAMP_TBL VALUES ('2000-03-15 13:14:02 GMT-1');
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
INSERT INTO TIMESTAMP_TBL VALUES ('2000-03-15 12:14:03 GMT-2');
INSERT INTO TIMESTAMP_TBL VALUES ('2000-03-15 03:14:04 PST+8');
INSERT INTO TIMESTAMP_TBL VALUES ('2000-03-15 02:14:05 MST+7:00');
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Variations for acceptable input formats
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 10 17:32:01 1997 -0800');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 10 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 10 5:32PM 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('1997/02/10 17:32:01-0800');
INSERT INTO TIMESTAMP_TBL VALUES ('1997-02-10 17:32:01 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb-10-1997 17:32:01 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('02-10-1997 17:32:01 PST');
INSERT INTO TIMESTAMP_TBL VALUES ('19970210 173201 PST');
Apply (a somewhat revised version of) Greg Mullane's patch to eliminate heuristic determination of day vs month in date/time input. Add the ability to specify that input is interpreted as yy-mm-dd order (which formerly worked, but only for yy greater than 31). DateStyle's input component now has the preferred spellings DMY, MDY, or YMD; the older keywords European and US are now aliases for the first two of these. Per recent discussions on pgsql-general.
2003-07-29 02:03:19 +02:00
set datestyle to ymd;
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('97FEB10 5:32:01PM UTC');
INSERT INTO TIMESTAMP_TBL VALUES ('97/02/10 17:32:01 UTC');
Apply (a somewhat revised version of) Greg Mullane's patch to eliminate heuristic determination of day vs month in date/time input. Add the ability to specify that input is interpreted as yy-mm-dd order (which formerly worked, but only for yy greater than 31). DateStyle's input component now has the preferred spellings DMY, MDY, or YMD; the older keywords European and US are now aliases for the first two of these. Per recent discussions on pgsql-general.
2003-07-29 02:03:19 +02:00
reset datestyle;
INSERT INTO TIMESTAMP_TBL VALUES ('1997.041 17:32:01 UTC');
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
INSERT INTO TIMESTAMP_TBL VALUES ('19970210 173201 America/New_York');
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
-- this fails (even though TZ is a no-op, we still look it up)
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
INSERT INTO TIMESTAMP_TBL VALUES ('19970710 173201 America/Does_not_exist');
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
ERROR: time zone "america/does_not_exist" not recognized
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Check date conversion and date arithmetic
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('1997-06-10 18:32:01 PDT');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 10 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 11 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 12 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 13 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 14 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 15 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 0097 BC');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 0097');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 0597');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 1097');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 1697');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 1797');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 1897');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 2097');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 28 17:32:01 1996');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 29 17:32:01 1996');
INSERT INTO TIMESTAMP_TBL VALUES ('Mar 01 17:32:01 1996');
INSERT INTO TIMESTAMP_TBL VALUES ('Dec 30 17:32:01 1996');
INSERT INTO TIMESTAMP_TBL VALUES ('Dec 31 17:32:01 1996');
INSERT INTO TIMESTAMP_TBL VALUES ('Jan 01 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 28 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 29 17:32:01 1997');
Adjust date/time input parsing code to correctly distinguish the four SQLSTATE error codes required by SQL99 (invalid format, datetime field overflow, interval field overflow, invalid time zone displacement value). Also emit a HINT about DateStyle in cases where it seems appropriate. Per recent gripes.
2003-08-28 01:29:29 +02:00
ERROR: date/time field value out of range: "Feb 29 17:32:01 1997"
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('Mar 01 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Dec 30 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Dec 31 17:32:01 1997');
INSERT INTO TIMESTAMP_TBL VALUES ('Dec 31 17:32:01 1999');
INSERT INTO TIMESTAMP_TBL VALUES ('Jan 01 17:32:01 2000');
INSERT INTO TIMESTAMP_TBL VALUES ('Dec 31 17:32:01 2000');
INSERT INTO TIMESTAMP_TBL VALUES ('Jan 01 17:32:01 2001');
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Currently unsupported syntax and ranges
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_TBL VALUES ('Feb 16 17:32:01 -0097');
Adjust date/time input parsing code to correctly distinguish the four SQLSTATE error codes required by SQL99 (invalid format, datetime field overflow, interval field overflow, invalid time zone displacement value). Also emit a HINT about DateStyle in cases where it seems appropriate. Per recent gripes.
2003-08-28 01:29:29 +02:00
ERROR: time zone displacement out of range: "Feb 16 17:32:01 -0097"
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
INSERT INTO TIMESTAMP_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 TIMESTAMP_TBL;
64 | d1
----+-----------------------------
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| -infinity
| infinity
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
| Thu Jan 01 00:00:00 1970
| Mon Feb 10 17:32:01 1997
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
| Mon Feb 10 17:32:02 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
| Mon Feb 10 17:32:01.40 1997
| Mon Feb 10 17:32:01.50 1997
| Mon Feb 10 17:32:01.60 1997
| Thu Jan 02 00:00:00 1997
| Thu Jan 02 03:04:05 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Jun 10 17:32:01 1997
| Sat Sep 22 18:19:20 2001
| Wed Mar 15 08:14:01 2000
| Wed Mar 15 13:14:02 2000
| Wed Mar 15 12:14:03 2000
| Wed Mar 15 03:14:04 2000
| Wed Mar 15 02:14:05 2000
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:00 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| Mon Feb 10 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
| Tue Jun 10 18:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Feb 11 17:32:01 1997
| Wed Feb 12 17:32:01 1997
| Thu Feb 13 17:32:01 1997
| Fri Feb 14 17:32:01 1997
| Sat Feb 15 17:32:01 1997
| Sun Feb 16 17:32:01 1997
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
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01: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
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
| Sun Feb 16 17:32:01 1997
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| Sat Feb 16 17:32:01 2097
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 Feb 28 17:32:01 1996
| Thu Feb 29 17:32:01 1996
| Fri Mar 01 17:32:01 1996
| Mon Dec 30 17:32:01 1996
| Tue Dec 31 17:32:01 1996
| Wed Jan 01 17:32:01 1997
| Fri Feb 28 17:32:01 1997
| Sat Mar 01 17:32:01 1997
| Tue Dec 30 17:32:01 1997
| Wed Dec 31 17:32:01 1997
| Fri Dec 31 17:32:01 1999
| Sat Jan 01 17:32:01 2000
| Sun Dec 31 17:32:01 2000
| Mon Jan 01 17:32:01 2001
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
Verified output from new psql. Include a few new tests for datetime/timespan arithmetic.
2000-01-05 07:06:23 +01:00
-- Demonstrate functions and operators
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 "48", d1 FROM TIMESTAMP_TBL
WHERE d1 > timestamp without time zone '1997-01-02';
48 | d1
----+-----------------------------
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| infinity
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 1997
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
| Mon Feb 10 17:32:02 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
| Mon Feb 10 17:32:01.40 1997
| Mon Feb 10 17:32:01.50 1997
| Mon Feb 10 17:32:01.60 1997
| Thu Jan 02 03:04:05 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Jun 10 17:32:01 1997
| Sat Sep 22 18:19:20 2001
| Wed Mar 15 08:14:01 2000
| Wed Mar 15 13:14:02 2000
| Wed Mar 15 12:14:03 2000
| Wed Mar 15 03:14:04 2000
| Wed Mar 15 02:14:05 2000
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:00 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| Mon Feb 10 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
| Tue Jun 10 18:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Feb 11 17:32:01 1997
| Wed Feb 12 17:32:01 1997
| Thu Feb 13 17:32:01 1997
| Fri Feb 14 17:32:01 1997
| Sat Feb 15 17:32:01 1997
| Sun Feb 16 17:32:01 1997
| Sun Feb 16 17:32:01 1997
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| Sat Feb 16 17:32:01 2097
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
| Fri Feb 28 17:32:01 1997
| Sat Mar 01 17:32:01 1997
| Tue Dec 30 17:32:01 1997
| Wed Dec 31 17:32:01 1997
| Fri Dec 31 17:32:01 1999
| Sat Jan 01 17:32:01 2000
| Sun Dec 31 17:32:01 2000
| Mon Jan 01 17:32:01 2001
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(49 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
SELECT '' AS "15", d1 FROM TIMESTAMP_TBL
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
WHERE d1 < timestamp without time zone '1997-01-02';
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
15 | d1
----+-----------------------------
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| -infinity
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
| Thu Jan 01 00:00:00 1970
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
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01: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
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 Feb 28 17:32:01 1996
| Thu Feb 29 17:32:01 1996
| Fri Mar 01 17:32:01 1996
| Mon Dec 30 17:32:01 1996
| Tue Dec 31 17:32:01 1996
| Wed Jan 01 17:32:01 1997
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(15 rows)
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
SELECT '' AS one, d1 FROM TIMESTAMP_TBL
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
WHERE d1 = timestamp without time zone '1997-01-02';
one | d1
-----+--------------------------
| Thu Jan 02 00:00:00 1997
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(1 row)
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 "63", d1 FROM TIMESTAMP_TBL
WHERE d1 != timestamp without time zone '1997-01-02';
63 | d1
----+-----------------------------
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| -infinity
| infinity
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
| Thu Jan 01 00:00:00 1970
| Mon Feb 10 17:32:01 1997
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
| Mon Feb 10 17:32:02 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
| Mon Feb 10 17:32:01.40 1997
| Mon Feb 10 17:32:01.50 1997
| Mon Feb 10 17:32:01.60 1997
| Thu Jan 02 03:04:05 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Jun 10 17:32:01 1997
| Sat Sep 22 18:19:20 2001
| Wed Mar 15 08:14:01 2000
| Wed Mar 15 13:14:02 2000
| Wed Mar 15 12:14:03 2000
| Wed Mar 15 03:14:04 2000
| Wed Mar 15 02:14:05 2000
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:00 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| Mon Feb 10 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
| Tue Jun 10 18:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Feb 11 17:32:01 1997
| Wed Feb 12 17:32:01 1997
| Thu Feb 13 17:32:01 1997
| Fri Feb 14 17:32:01 1997
| Sat Feb 15 17:32:01 1997
| Sun Feb 16 17:32:01 1997
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
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01: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
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
| Sun Feb 16 17:32:01 1997
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| Sat Feb 16 17:32:01 2097
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 Feb 28 17:32:01 1996
| Thu Feb 29 17:32:01 1996
| Fri Mar 01 17:32:01 1996
| Mon Dec 30 17:32:01 1996
| Tue Dec 31 17:32:01 1996
| Wed Jan 01 17:32:01 1997
| Fri Feb 28 17:32:01 1997
| Sat Mar 01 17:32:01 1997
| Tue Dec 30 17:32:01 1997
| Wed Dec 31 17:32:01 1997
| Fri Dec 31 17:32:01 1999
| Sat Jan 01 17:32:01 2000
| Sun Dec 31 17:32:01 2000
| Mon Jan 01 17:32:01 2001
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(64 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
SELECT '' AS "16", d1 FROM TIMESTAMP_TBL
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
WHERE d1 <= timestamp without time zone '1997-01-02';
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
16 | d1
----+-----------------------------
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| -infinity
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
| Thu Jan 01 00:00:00 1970
| Thu Jan 02 00:00:00 1997
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
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01: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
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 Feb 28 17:32:01 1996
| Thu Feb 29 17:32:01 1996
| Fri Mar 01 17:32:01 1996
| Mon Dec 30 17:32:01 1996
| Tue Dec 31 17:32:01 1996
| Wed Jan 01 17:32:01 1997
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
(16 rows)
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 "49", d1 FROM TIMESTAMP_TBL
WHERE d1 >= timestamp without time zone '1997-01-02';
49 | d1
----+-----------------------------
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| infinity
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 1997
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
| Mon Feb 10 17:32:02 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
| Mon Feb 10 17:32:01.40 1997
| Mon Feb 10 17:32:01.50 1997
| Mon Feb 10 17:32:01.60 1997
| Thu Jan 02 00:00:00 1997
| Thu Jan 02 03:04:05 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Jun 10 17:32:01 1997
| Sat Sep 22 18:19:20 2001
| Wed Mar 15 08:14:01 2000
| Wed Mar 15 13:14:02 2000
| Wed Mar 15 12:14:03 2000
| Wed Mar 15 03:14:04 2000
| Wed Mar 15 02:14:05 2000
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:00 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
| Mon Feb 10 17:32:01 1997
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| Mon Feb 10 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
| Tue Jun 10 18:32:01 1997
| Mon Feb 10 17:32:01 1997
| Tue Feb 11 17:32:01 1997
| Wed Feb 12 17:32:01 1997
| Thu Feb 13 17:32:01 1997
| Fri Feb 14 17:32:01 1997
| Sat Feb 15 17:32:01 1997
| Sun Feb 16 17:32:01 1997
| Sun Feb 16 17:32:01 1997
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| Sat Feb 16 17:32:01 2097
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
| Fri Feb 28 17:32:01 1997
| Sat Mar 01 17:32:01 1997
| Tue Dec 30 17:32:01 1997
| Wed Dec 31 17:32:01 1997
| Fri Dec 31 17:32:01 1999
| Sat Jan 01 17:32:01 2000
| Sun Dec 31 17:32:01 2000
| Mon Jan 01 17:32:01 2001
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(50 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
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 "54", d1 - timestamp without time zone '1997-01-02' AS diff
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
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 | diff
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
----+----------------------------------------
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
| @ 9863 days ago
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 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
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01: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
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
| @ 159 days 17 hours 32 mins 1 sec
| @ 1724 days 18 hours 19 mins 20 secs
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 1168 days 8 hours 14 mins 1 sec
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 13 hours 14 mins 2 secs
| @ 1168 days 12 hours 14 mins 3 secs
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 1168 days 3 hours 14 mins 4 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 2 hours 14 mins 5 secs
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 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
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 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| @ 39 days 17 hours 32 mins 1 sec
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
| @ 159 days 18 hours 32 mins 1 sec
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(55 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
Per a brief conversation with Tom, I've created a patch for adding support for 'week' within the date_trunc function. Within the patch I added a couple of test cases and associated target output, and changed the documentation to add 'week' appropriately. Robert Creager
2004-03-05 03:41:14 +01:00
SELECT '' AS date_trunc_week, date_trunc( 'week', timestamp '2004-02-29 15:44:17.71393' ) AS week_trunc;
date_trunc_week | week_trunc
-----------------+--------------------------
| Mon Feb 23 00:00:00 2004
(1 row)
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
-- Test casting within a BETWEEN qualifier
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 "54", d1 - timestamp without time zone '1997-01-02' AS diff
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
FROM TIMESTAMP_TBL
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
WHERE d1 BETWEEN timestamp without time zone '1902-01-01'
AND timestamp without time zone '2038-01-01';
54 | diff
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
----+----------------------------------------
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
| @ 9863 days ago
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 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
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01: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
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
| @ 159 days 17 hours 32 mins 1 sec
| @ 1724 days 18 hours 19 mins 20 secs
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 1168 days 8 hours 14 mins 1 sec
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 13 hours 14 mins 2 secs
| @ 1168 days 12 hours 14 mins 3 secs
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 1168 days 3 hours 14 mins 4 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 2 hours 14 mins 5 secs
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 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
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 sec
| @ 39 days 17 hours 32 mins 1 sec
| @ 39 days 17 hours 32 mins 1 sec
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| @ 39 days 17 hours 32 mins 1 sec
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
| @ 159 days 18 hours 32 mins 1 sec
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| @ 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(55 rows)
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
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 "timestamp",
date_part( 'year', d1) AS year, date_part( 'month', d1) AS month,
*shrug* I don't know anymore...
1997-04-27 05:57:34 +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
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
FROM TIMESTAMP_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 | timestamp | year | month | day | hour | minute | second
----+-----------------------------+------+-------+-----+------+--------+--------
| Thu Jan 01 00:00:00 1970 | 1970 | 1 | 1 | 0 | 0 | 0
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:02 1997 | 1997 | 2 | 10 | 17 | 32 | 2
| Mon Feb 10 17:32:01.40 1997 | 1997 | 2 | 10 | 17 | 32 | 1.4
| Mon Feb 10 17:32:01.50 1997 | 1997 | 2 | 10 | 17 | 32 | 1.5
| Mon Feb 10 17:32:01.60 1997 | 1997 | 2 | 10 | 17 | 32 | 1.6
| Thu Jan 02 00:00:00 1997 | 1997 | 1 | 2 | 0 | 0 | 0
| Thu Jan 02 03:04:05 1997 | 1997 | 1 | 2 | 3 | 4 | 5
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Tue Jun 10 17:32:01 1997 | 1997 | 6 | 10 | 17 | 32 | 1
| Sat Sep 22 18:19:20 2001 | 2001 | 9 | 22 | 18 | 19 | 20
| Wed Mar 15 08:14:01 2000 | 2000 | 3 | 15 | 8 | 14 | 1
| Wed Mar 15 13:14:02 2000 | 2000 | 3 | 15 | 13 | 14 | 2
| Wed Mar 15 12:14:03 2000 | 2000 | 3 | 15 | 12 | 14 | 3
| Wed Mar 15 03:14:04 2000 | 2000 | 3 | 15 | 3 | 14 | 4
| Wed Mar 15 02:14:05 2000 | 2000 | 3 | 15 | 2 | 14 | 5
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:00 1997 | 1997 | 2 | 10 | 17 | 32 | 0
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
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
| Tue Jun 10 18:32:01 1997 | 1997 | 6 | 10 | 18 | 32 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 2 | 10 | 17 | 32 | 1
| Tue Feb 11 17:32:01 1997 | 1997 | 2 | 11 | 17 | 32 | 1
| Wed Feb 12 17:32:01 1997 | 1997 | 2 | 12 | 17 | 32 | 1
| Thu Feb 13 17:32:01 1997 | 1997 | 2 | 13 | 17 | 32 | 1
| Fri Feb 14 17:32:01 1997 | 1997 | 2 | 14 | 17 | 32 | 1
| Sat Feb 15 17:32:01 1997 | 1997 | 2 | 15 | 17 | 32 | 1
| Sun Feb 16 17:32:01 1997 | 1997 | 2 | 16 | 17 | 32 | 1
| Sun Feb 16 17:32:01 1997 | 1997 | 2 | 16 | 17 | 32 | 1
| Wed Feb 28 17:32:01 1996 | 1996 | 2 | 28 | 17 | 32 | 1
| Thu Feb 29 17:32:01 1996 | 1996 | 2 | 29 | 17 | 32 | 1
| Fri Mar 01 17:32:01 1996 | 1996 | 3 | 1 | 17 | 32 | 1
| Mon Dec 30 17:32:01 1996 | 1996 | 12 | 30 | 17 | 32 | 1
| Tue Dec 31 17:32:01 1996 | 1996 | 12 | 31 | 17 | 32 | 1
| Wed Jan 01 17:32:01 1997 | 1997 | 1 | 1 | 17 | 32 | 1
| Fri Feb 28 17:32:01 1997 | 1997 | 2 | 28 | 17 | 32 | 1
| Sat Mar 01 17:32:01 1997 | 1997 | 3 | 1 | 17 | 32 | 1
| Tue Dec 30 17:32:01 1997 | 1997 | 12 | 30 | 17 | 32 | 1
| Wed Dec 31 17:32:01 1997 | 1997 | 12 | 31 | 17 | 32 | 1
| Fri Dec 31 17:32:01 1999 | 1999 | 12 | 31 | 17 | 32 | 1
| Sat Jan 01 17:32:01 2000 | 2000 | 1 | 1 | 17 | 32 | 1
| Sun Dec 31 17:32:01 2000 | 2000 | 12 | 31 | 17 | 32 | 1
| Mon Jan 01 17:32:01 2001 | 2001 | 1 | 1 | 17 | 32 | 1
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(55 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
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 "timestamp",
date_part( 'quarter', d1) AS quarter, date_part( 'msec', d1) AS msec,
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
date_part( 'usec', d1) AS usec
All regression tests pass except for rules.sql (unrelated). Implement "date/time grand unification". Transform datetime and timespan into timestamp and interval. Deprecate datetime and timespan, though translate to new types in gram.y. Transform all datetime and timespan catalog entries into new types. Make "INTERVAL" reserved word allowed as a column identifier in gram.y. Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility routines for all date/time types. date.{h,c} now deals with date, time types. timestamp.{h,c} now deals with timestamp, interval types. nabstime.{h,c} now deals with abstime, reltime, tinterval types. Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:27:27 +01:00
FROM TIMESTAMP_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 | timestamp | quarter | msec | usec
----+-----------------------------+---------+-------+----------
| Thu Jan 01 00:00:00 1970 | 1 | 0 | 0
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:02 1997 | 1 | 2000 | 2000000
| Mon Feb 10 17:32:01.40 1997 | 1 | 1400 | 1400000
| Mon Feb 10 17:32:01.50 1997 | 1 | 1500 | 1500000
| Mon Feb 10 17:32:01.60 1997 | 1 | 1600 | 1600000
| Thu Jan 02 00:00:00 1997 | 1 | 0 | 0
| Thu Jan 02 03:04:05 1997 | 1 | 5000 | 5000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Tue Jun 10 17:32:01 1997 | 2 | 1000 | 1000000
| Sat Sep 22 18:19:20 2001 | 3 | 20000 | 20000000
| Wed Mar 15 08:14:01 2000 | 1 | 1000 | 1000000
| Wed Mar 15 13:14:02 2000 | 1 | 2000 | 2000000
| Wed Mar 15 12:14:03 2000 | 1 | 3000 | 3000000
| Wed Mar 15 03:14:04 2000 | 1 | 4000 | 4000000
| Wed Mar 15 02:14:05 2000 | 1 | 5000 | 5000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:00 1997 | 1 | 0 | 0
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
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
| Tue Jun 10 18:32:01 1997 | 2 | 1000 | 1000000
| Mon Feb 10 17:32:01 1997 | 1 | 1000 | 1000000
| Tue Feb 11 17:32:01 1997 | 1 | 1000 | 1000000
| Wed Feb 12 17:32:01 1997 | 1 | 1000 | 1000000
| Thu Feb 13 17:32:01 1997 | 1 | 1000 | 1000000
| Fri Feb 14 17:32:01 1997 | 1 | 1000 | 1000000
| Sat Feb 15 17:32:01 1997 | 1 | 1000 | 1000000
| Sun Feb 16 17:32:01 1997 | 1 | 1000 | 1000000
| Sun Feb 16 17:32:01 1997 | 1 | 1000 | 1000000
| Wed Feb 28 17:32:01 1996 | 1 | 1000 | 1000000
| Thu Feb 29 17:32:01 1996 | 1 | 1000 | 1000000
| Fri Mar 01 17:32:01 1996 | 1 | 1000 | 1000000
| Mon Dec 30 17:32:01 1996 | 4 | 1000 | 1000000
| Tue Dec 31 17:32:01 1996 | 4 | 1000 | 1000000
| Wed Jan 01 17:32:01 1997 | 1 | 1000 | 1000000
| Fri Feb 28 17:32:01 1997 | 1 | 1000 | 1000000
| Sat Mar 01 17:32:01 1997 | 1 | 1000 | 1000000
| Tue Dec 30 17:32:01 1997 | 4 | 1000 | 1000000
| Wed Dec 31 17:32:01 1997 | 4 | 1000 | 1000000
| Fri Dec 31 17:32:01 1999 | 4 | 1000 | 1000000
| Sat Jan 01 17:32:01 2000 | 1 | 1000 | 1000000
| Sun Dec 31 17:32:01 2000 | 4 | 1000 | 1000000
| Mon Jan 01 17:32:01 2001 | 1 | 1000 | 1000000
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(55 rows)
*shrug* I don't know anymore...
1997-04-27 05:57:34 +02:00
Add two new format fields for use with to_char(), to_date() and to_timestamp(): - ID for day-of-week - IDDD for day-of-year This makes it possible to convert ISO week dates to and from text fully represented in either week ('IYYY-IW-ID') or day-of-year ('IYYY-IDDD') format. I have also added an 'isoyear' field for use with extract / date_part. Brendan Jurd
2007-02-16 04:39:46 +01:00
SELECT '' AS "54", d1 as "timestamp",
date_part( 'isoyear', d1) AS isoyear, date_part( 'week', d1) AS week,
date_part( 'dow', d1) AS dow
FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
54 | timestamp | isoyear | week | dow
----+-----------------------------+---------+------+-----
| Thu Jan 01 00:00:00 1970 | 1970 | 1 | 4
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:02 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01.40 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01.50 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01.60 1997 | 1997 | 7 | 1
| Thu Jan 02 00:00:00 1997 | 1997 | 1 | 4
| Thu Jan 02 03:04:05 1997 | 1997 | 1 | 4
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Tue Jun 10 17:32:01 1997 | 1997 | 24 | 2
| Sat Sep 22 18:19:20 2001 | 2001 | 38 | 6
| Wed Mar 15 08:14:01 2000 | 2000 | 11 | 3
| Wed Mar 15 13:14:02 2000 | 2000 | 11 | 3
| Wed Mar 15 12:14:03 2000 | 2000 | 11 | 3
| Wed Mar 15 03:14:04 2000 | 2000 | 11 | 3
| Wed Mar 15 02:14:05 2000 | 2000 | 11 | 3
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:00 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Tue Jun 10 18:32:01 1997 | 1997 | 24 | 2
| Mon Feb 10 17:32:01 1997 | 1997 | 7 | 1
| Tue Feb 11 17:32:01 1997 | 1997 | 7 | 2
| Wed Feb 12 17:32:01 1997 | 1997 | 7 | 3
| Thu Feb 13 17:32:01 1997 | 1997 | 7 | 4
| Fri Feb 14 17:32:01 1997 | 1997 | 7 | 5
| Sat Feb 15 17:32:01 1997 | 1997 | 7 | 6
| Sun Feb 16 17:32:01 1997 | 1997 | 7 | 0
| Sun Feb 16 17:32:01 1997 | 1997 | 7 | 0
| Wed Feb 28 17:32:01 1996 | 1996 | 9 | 3
| Thu Feb 29 17:32:01 1996 | 1996 | 9 | 4
| Fri Mar 01 17:32:01 1996 | 1996 | 9 | 5
| Mon Dec 30 17:32:01 1996 | 1997 | 1 | 1
| Tue Dec 31 17:32:01 1996 | 1997 | 1 | 2
| Wed Jan 01 17:32:01 1997 | 1997 | 1 | 3
| Fri Feb 28 17:32:01 1997 | 1997 | 9 | 5
| Sat Mar 01 17:32:01 1997 | 1997 | 9 | 6
| Tue Dec 30 17:32:01 1997 | 1998 | 1 | 2
| Wed Dec 31 17:32:01 1997 | 1998 | 1 | 3
| Fri Dec 31 17:32:01 1999 | 1999 | 52 | 5
| Sat Jan 01 17:32:01 2000 | 1999 | 52 | 6
| Sun Dec 31 17:32:01 2000 | 2000 | 52 | 0
| Mon Jan 01 17:32:01 2001 | 2001 | 1 | 1
(55 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
-- TO_CHAR()
SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon')
FROM TIMESTAMP_TBL;
to_char_1 | to_char
-----------+------------------------------------------------------------------------------------------
|
|
| 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
| 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
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
| SATURDAY Saturday saturday SAT Sat sat SEPTEMBER September september IX SEP Sep sep
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
| MONDAY Monday monday MON Mon mon FEBRUARY February february II FEB Feb feb
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
SELECT '' AS to_char_2, to_char(d1, 'FMDAY FMDay FMday FMMONTH FMMonth FMmonth FMRM')
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
FROM TIMESTAMP_TBL;
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
to_char_2 | to_char
-----------+--------------------------------------------------------------
|
|
| 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
| 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
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
| SATURDAY Saturday saturday SEPTEMBER September september IX
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
| MONDAY Monday monday FEBRUARY February february II
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
SELECT '' AS to_char_3, to_char(d1, 'Y,YYY YYYY YYY YY Y CC Q MM WW DDD DD D J')
FROM TIMESTAMP_TBL;
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
to_char_3 | to_char
-----------+-------------------------------------------------
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
|
|
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 1,970 1970 970 70 0 20 1 01 01 001 01 5 2440588
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
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
| 2,001 2001 001 01 1 21 3 09 38 265 22 7 2452175
Fix handling of CC (century) format spec in to_date/to_char. According to standard convention the 21st century runs from 2001-2100, not 2000-2099, so make it work like that. Per bug #2885 from Akio Iwaasa. Backpatch to 8.2, but no further, since this is really a definitional change; users of older branches are probably more interested in stability.
2007-01-13 00:34:55 +01:00
| 2,000 2000 000 00 0 20 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 20 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 20 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 20 1 03 11 075 15 4 2451619
| 2,000 2000 000 00 0 20 1 03 11 075 15 4 2451619
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
| 1,997 1997 997 97 7 20 1 02 06 041 10 2 2450490
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 1,997 1997 997 97 7 20 1 02 07 047 16 1 2450496
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
| 0,097 0097 097 97 7 01 1 02 07 047 16 3 1686042
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 0,097 0097 097 97 7 01 1 02 07 047 16 7 1756536
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 1,697 1697 697 97 7 17 1 02 07 047 16 7 2340924
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 2,097 2097 097 97 7 21 1 02 07 047 16 7 2487021
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 1,997 1997 997 97 7 20 4 12 52 364 30 3 2450813
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Fix handling of CC (century) format spec in to_date/to_char. According to standard convention the 21st century runs from 2001-2100, not 2000-2099, so make it work like that. Per bug #2885 from Akio Iwaasa. Backpatch to 8.2, but no further, since this is really a definitional change; users of older branches are probably more interested in stability.
2007-01-13 00:34:55 +01:00
| 2,000 2000 000 00 0 20 1 01 01 001 01 7 2451545
| 2,000 2000 000 00 0 20 4 12 53 366 31 1 2451910
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 2,001 2001 001 01 1 21 1 01 01 001 01 2 2451911
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
SELECT '' AS to_char_4, to_char(d1, 'FMY,YYY FMYYYY FMYYY FMYY FMY FMCC FMQ FMMM FMWW FMDDD FMDD FMD FMJ')
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
FROM TIMESTAMP_TBL;
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
to_char_4 | to_char
-----------+-------------------------------------------------
|
|
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 1,970 1970 970 70 0 20 1 1 1 1 1 5 2440588
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
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
| 2,001 2001 001 01 1 21 3 9 38 265 22 7 2452175
Fix handling of CC (century) format spec in to_date/to_char. According to standard convention the 21st century runs from 2001-2100, not 2000-2099, so make it work like that. Per bug #2885 from Akio Iwaasa. Backpatch to 8.2, but no further, since this is really a definitional change; users of older branches are probably more interested in stability.
2007-01-13 00:34:55 +01:00
| 2,000 2000 000 00 0 20 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 20 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 20 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 20 1 3 11 75 15 4 2451619
| 2,000 2000 000 00 0 20 1 3 11 75 15 4 2451619
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
| 1,997 1997 997 97 7 20 1 2 6 41 10 2 2450490
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 1,997 1997 997 97 7 20 1 2 7 47 16 1 2450496
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
| 0,097 97 097 97 7 1 1 2 7 47 16 3 1686042
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 0,097 97 097 97 7 1 1 2 7 47 16 7 1756536
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 1,697 1697 697 97 7 17 1 2 7 47 16 7 2340924
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 2,097 2097 097 97 7 21 1 2 7 47 16 7 2487021
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 1,997 1997 997 97 7 20 4 12 52 364 30 3 2450813
In the attache is new (correct) version. I add TZ (timezone) support for to_char() too. Karel
2000-07-03 18:01:33 +02:00
| 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
Fix handling of CC (century) format spec in to_date/to_char. According to standard convention the 21st century runs from 2001-2100, not 2000-2099, so make it work like that. Per bug #2885 from Akio Iwaasa. Backpatch to 8.2, but no further, since this is really a definitional change; users of older branches are probably more interested in stability.
2007-01-13 00:34:55 +01:00
| 2,000 2000 000 00 0 20 1 1 1 1 1 7 2451545
| 2,000 2000 000 00 0 20 4 12 53 366 31 1 2451910
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 2,001 2001 001 01 1 21 1 1 1 1 1 2 2451911
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
SELECT '' AS to_char_5, to_char(d1, 'HH HH12 HH24 MI SS SSSS')
FROM TIMESTAMP_TBL;
to_char_5 | to_char
-----------+----------------------
|
|
| 12 12 00 00 00 0
| 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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01: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
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
| 06 06 18 19 20 65960
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 08 08 08 14 01 29641
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
| 01 01 13 14 02 47642
| 12 12 12 14 03 44043
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 03 03 03 14 04 11644
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
| 02 02 02 14 05 8045
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
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
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| 05 05 17 32 01 63121
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
Add E'' syntax so eventually normal strings can treat backslashes literally. Add GUC variables: "escape_string_warning" - warn about backslashes in non-E strings "escape_string_syntax" - supports E'' syntax? "standard_compliant_strings" - treats backslashes literally in '' Update code to use E'' when escapes are used.
2005-06-26 05:04:37 +02:00
SELECT '' AS to_char_6, to_char(d1, E'"HH:MI:SS is" HH:MI:SS "\\"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
FROM TIMESTAMP_TBL;
to_char_6 | to_char
-----------+-------------------------------------------------
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
|
|
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 12: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"
| HH:MI:SS is 06:19:20 "text between quote marks"
| HH:MI:SS is 08:14:01 "text between quote marks"
| HH:MI:SS is 01:14:02 "text between quote marks"
| HH:MI:SS is 12:14:03 "text between quote marks"
| HH:MI:SS is 03:14:04 "text between quote marks"
| HH:MI:SS is 02: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 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 up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| HH:MI:SS is 05:32:01 "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 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"
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
SELECT '' AS to_char_7, to_char(d1, 'HH24--text--MI--text--SS')
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
FROM TIMESTAMP_TBL;
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
to_char_7 | to_char
-----------+------------------------
|
|
| 00--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
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01: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
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
| 18--text--19--text--20
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 08--text--14--text--01
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
| 13--text--14--text--02
| 12--text--14--text--03
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 03--text--14--text--04
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
| 02--text--14--text--05
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
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
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| 17--text--32--text--01
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
SELECT '' AS to_char_8, to_char(d1, 'YYYYTH YYYYth Jth')
FROM TIMESTAMP_TBL;
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
to_char_8 | to_char
-----------+-------------------------
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
|
|
| 1970TH 1970th 2440588th
| 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
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
| 2001ST 2001st 2452175th
Support full POSIX-style time zone: EST+3, PST-3, etc. We probably support a superset of the spec, but I don't have the spec to confirm this. Update regression tests to include tests for this format. Update geometry.out with results from Linux RH 5.2 system (for last decimal place).
2000-03-16 15:38:31 +01:00
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
| 2000TH 2000th 2451619th
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
| 1997TH 1997th 2450490th
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 1997TH 1997th 2450610th
| 1997TH 1997th 2450490th
| 1997TH 1997th 2450491st
| 1997TH 1997th 2450492nd
| 1997TH 1997th 2450493rd
| 1997TH 1997th 2450494th
| 1997TH 1997th 2450495th
| 1997TH 1997th 2450496th
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
| 0097TH 0097th 1686042nd
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 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
Clean up regression for new 1st/9th/3rd fixes.
2000-06-09 13:40:03 +02:00
| 1997TH 1997th 2450813th
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
| 1997TH 1997th 2450814th
| 1999TH 1999th 2451544th
| 2000TH 2000th 2451545th
| 2000TH 2000th 2451910th
Clean up regression for new 1st/9th/3rd fixes.
2000-06-09 13:40:03 +02:00
| 2001ST 2001st 2451911th
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
SELECT '' AS to_char_9, to_char(d1, 'YYYY A.D. YYYY a.d. YYYY bc HH:MI:SS P.M. HH:MI:SS p.m. HH:MI:SS pm')
FROM TIMESTAMP_TBL;
to_char_9 | to_char
-----------+---------------------------------------------------------------------
|
|
| 1970 A.D. 1970 a.d. 1970 ad 12:00:00 A.M. 12:00:00 a.m. 12:00:00 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
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
Update create_rule manual page.
2000-04-07 21:17:51 +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
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
| 2001 A.D. 2001 a.d. 2001 ad 06:19:20 P.M. 06:19:20 p.m. 06:19:20 pm
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
| 2000 A.D. 2000 a.d. 2000 ad 08:14:01 A.M. 08:14:01 a.m. 08:14:01 am
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 01:14:02 P.M. 01:14:02 p.m. 01:14:02 pm
| 2000 A.D. 2000 a.d. 2000 ad 12:14:03 P.M. 12:14:03 p.m. 12:14:03 pm
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
| 2000 A.D. 2000 a.d. 2000 ad 03:14:04 A.M. 03:14:04 a.m. 03:14:04 am
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 02:14:05 A.M. 02:14:05 a.m. 02:14:05 am
Update create_rule manual page.
2000-04-07 21:17:51 +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: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
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
Fix up some problems in handling of zic-style time zone names in datetime input routines. Remove the former "DecodePosixTimezone" function in favor of letting the zic code handle POSIX-style zone specs (see tzparse()). In particular this means that "PST+3" now means the same as "-03", whereas it used to mean "-11" --- the zone abbreviation is effectively just a noise word in this syntax. Make sure that all named and POSIX-style zone names will be parsed as a single token. Fix long-standing bogosities in printing and input of fractional-hour timezone offsets (since the tzparse() code will accept these, we'd better make 'em work). Also correct an error in the original coding of the zic-zone-name patch: in "timestamp without time zone" input, zone names are supposed to be allowed but ignored, but the coding was such that the zone changed the interpretation anyway.
2006-10-17 23:03:21 +02:00
| 1997 A.D. 1997 a.d. 1997 ad 05:32:01 P.M. 05:32:01 p.m. 05:32:01 pm
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
| 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
Please find attached two patches for documentation and regression tests for the usage of full time zone names. Joachim Wieland
2006-07-06 03:46:38 +02:00
(65 rows)
Update create_rule manual page.
2000-04-07 21:17:51 +02:00
Add two new format fields for use with to_char(), to_date() and to_timestamp(): - ID for day-of-week - IDDD for day-of-year This makes it possible to convert ISO week dates to and from text fully represented in either week ('IYYY-IW-ID') or day-of-year ('IYYY-IDDD') format. I have also added an 'isoyear' field for use with extract / date_part. Brendan Jurd
2007-02-16 04:39:46 +01:00
SELECT '' AS to_char_10, to_char(d1, 'IYYY IYY IY I IW IDDD ID')
FROM TIMESTAMP_TBL;
to_char_10 | to_char
------------+------------------------
|
|
| 1970 970 70 0 01 004 4
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 01 004 4
| 1997 997 97 7 01 004 4
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 24 163 2
| 2001 001 01 1 38 265 6
| 2000 000 00 0 11 073 3
| 2000 000 00 0 11 073 3
| 2000 000 00 0 11 073 3
| 2000 000 00 0 11 073 3
| 2000 000 00 0 11 073 3
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 043 1
| 1997 997 97 7 24 163 2
| 1997 997 97 7 07 043 1
| 1997 997 97 7 07 044 2
| 1997 997 97 7 07 045 3
| 1997 997 97 7 07 046 4
| 1997 997 97 7 07 047 5
| 1997 997 97 7 07 048 6
| 1997 997 97 7 07 049 7
| 0097 097 97 7 07 044 2
| 0097 097 97 7 07 048 6
| 0597 597 97 7 07 046 4
| 1097 097 97 7 07 044 2
| 1697 697 97 7 07 048 6
| 1797 797 97 7 07 046 4
| 1897 897 97 7 07 044 2
| 1997 997 97 7 07 049 7
| 2097 097 97 7 07 048 6
| 1996 996 96 6 09 059 3
| 1996 996 96 6 09 060 4
| 1996 996 96 6 09 061 5
| 1997 997 97 7 01 001 1
| 1997 997 97 7 01 002 2
| 1997 997 97 7 01 003 3
| 1997 997 97 7 09 061 5
| 1997 997 97 7 09 062 6
| 1998 998 98 8 01 002 2
| 1998 998 98 8 01 003 3
| 1999 999 99 9 52 362 5
| 1999 999 99 9 52 363 6
| 2000 000 00 0 52 364 7
| 2001 001 01 1 01 001 1
(65 rows)
SELECT '' AS to_char_11, to_char(d1, 'FMIYYY FMIYY FMIY FMI FMIW FMIDDD FMID')
FROM TIMESTAMP_TBL;
to_char_11 | to_char
------------+------------------------
|
|
| 1970 970 70 0 1 4 4
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 1 4 4
| 1997 997 97 7 1 4 4
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 24 163 2
| 2001 001 01 1 38 265 6
| 2000 000 00 0 11 73 3
| 2000 000 00 0 11 73 3
| 2000 000 00 0 11 73 3
| 2000 000 00 0 11 73 3
| 2000 000 00 0 11 73 3
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 43 1
| 1997 997 97 7 24 163 2
| 1997 997 97 7 7 43 1
| 1997 997 97 7 7 44 2
| 1997 997 97 7 7 45 3
| 1997 997 97 7 7 46 4
| 1997 997 97 7 7 47 5
| 1997 997 97 7 7 48 6
| 1997 997 97 7 7 49 7
| 97 097 97 7 7 44 2
| 97 097 97 7 7 48 6
| 597 597 97 7 7 46 4
| 1097 097 97 7 7 44 2
| 1697 697 97 7 7 48 6
| 1797 797 97 7 7 46 4
| 1897 897 97 7 7 44 2
| 1997 997 97 7 7 49 7
| 2097 097 97 7 7 48 6
| 1996 996 96 6 9 59 3
| 1996 996 96 6 9 60 4
| 1996 996 96 6 9 61 5
| 1997 997 97 7 1 1 1
| 1997 997 97 7 1 2 2
| 1997 997 97 7 1 3 3
| 1997 997 97 7 9 61 5
| 1997 997 97 7 9 62 6
| 1998 998 98 8 1 2 2
| 1998 998 98 8 1 3 3
| 1999 999 99 9 52 362 5
| 1999 999 99 9 52 363 6
| 2000 000 00 0 52 364 7
| 2001 001 01 1 1 1 1
(65 rows)
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
-- TO_TIMESTAMP()
SELECT '' AS to_timestamp_1, to_timestamp('0097/Feb/16 --> 08:14:30', 'YYYY/Mon/DD --> HH:MI:SS');
Adjust our timezone library to use pg_time_t (typedef'd as int64) in place of time_t, as per prior discussion. The behavior does not change on machines without a 64-bit-int type, but on machines with one, which is most, we are rid of the bizarre boundary behavior at the edges of the 32-bit-time_t range (1901 and 2038). The system will now treat times over the full supported timestamp range as being in your local time zone. It may seem a little bizarre to consider that times in 4000 BC are PST or EST, but this is surely at least as reasonable as propagating Gregorian calendar rules back that far. I did not modify the format of the zic timezone database files, which means that for the moment the system will not know about daylight-savings periods outside the range 1901-2038. Given the way the files are set up, it's not a simple decision like 'widen to 64 bits'; we have to actually think about the range of years that need to be supported. We should probably inquire what the plans of the upstream zic people are before making any decisions of our own.
2004-06-03 04:08:07 +02:00
to_timestamp_1 | to_timestamp
----------------+------------------------------
| Sat Feb 16 08:14:30 0097 PST
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
(1 row)
SELECT '' AS to_timestamp_2, to_timestamp('97/2/16 8:14:30', 'FMYYYY/FMMM/FMDD FMHH:FMMI:FMSS');
Adjust our timezone library to use pg_time_t (typedef'd as int64) in place of time_t, as per prior discussion. The behavior does not change on machines without a 64-bit-int type, but on machines with one, which is most, we are rid of the bizarre boundary behavior at the edges of the 32-bit-time_t range (1901 and 2038). The system will now treat times over the full supported timestamp range as being in your local time zone. It may seem a little bizarre to consider that times in 4000 BC are PST or EST, but this is surely at least as reasonable as propagating Gregorian calendar rules back that far. I did not modify the format of the zic timezone database files, which means that for the moment the system will not know about daylight-savings periods outside the range 1901-2038. Given the way the files are set up, it's not a simple decision like 'widen to 64 bits'; we have to actually think about the range of years that need to be supported. We should probably inquire what the plans of the upstream zic people are before making any decisions of our own.
2004-06-03 04:08:07 +02:00
to_timestamp_2 | to_timestamp
----------------+------------------------------
| Sat Feb 16 08:14:30 0097 PST
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
(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',
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
'"My birthday-> Year" YYYY, "Month:" FMMonth, "Day:" DD');
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
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');
Adjust our timezone library to use pg_time_t (typedef'd as int64) in place of time_t, as per prior discussion. The behavior does not change on machines without a 64-bit-int type, but on machines with one, which is most, we are rid of the bizarre boundary behavior at the edges of the 32-bit-time_t range (1901 and 2038). The system will now treat times over the full supported timestamp range as being in your local time zone. It may seem a little bizarre to consider that times in 4000 BC are PST or EST, but this is surely at least as reasonable as propagating Gregorian calendar rules back that far. I did not modify the format of the zic timezone database files, which means that for the moment the system will not know about daylight-savings periods outside the range 1901-2038. Given the way the files are set up, it's not a simple decision like 'widen to 64 bits'; we have to actually think about the range of years that need to be supported. We should probably inquire what the plans of the upstream zic people are before making any decisions of our own.
2004-06-03 04:08:07 +02:00
to_timestamp_5 | to_timestamp
----------------+------------------------------
| Sat Aug 21 00:00:00 1582 PST
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
(1 row)
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_6, to_timestamp('15 "text between quote marks" 98 54 45',
Add E'' syntax so eventually normal strings can treat backslashes literally. Add GUC variables: "escape_string_warning" - warn about backslashes in non-E strings "escape_string_syntax" - supports E'' syntax? "standard_compliant_strings" - treats backslashes literally in '' Update code to use E'' when escapes are used.
2005-06-26 05:04:37 +02:00
E'HH "\\text between quote marks\\"" YY MI SS');
here is a patch for formatting.c (to_char/timestampt()), for 7.1 it fixing Y,YY,YYY,YYYY conversion, the docs and regress tests update are included too. During the patch testing I found small bug in miscadmin.h in convertstr() declaration. Here it's fixed too. Thanks Karel
2000-11-25 06:00:33 +01:00
to_timestamp_6 | to_timestamp
----------------+------------------------------
| Thu Jan 01 15:54:45 1998 PST
Hi, the to_char() source code is large, here are regression tests for numeric/timestamp/int8 part. It is probably enough test for formatting code in the formatting.c module. The others (float4/float8/int4) types share this formatting code and eventual bugs for these types aren't few probable. Patch fix timestamp_to_char() for infinity/invalid timestamp too. Karel
2000-03-08 02:34:41 +01:00
(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)
here is a patch for formatting.c (to_char/timestampt()), for 7.1 it fixing Y,YY,YYY,YYYY conversion, the docs and regress tests update are included too. During the patch testing I found small bug in miscadmin.h in convertstr() declaration. Here it's fixed too. Thanks Karel
2000-11-25 06:00:33 +01:00
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
here is a patch for formatting.c (to_char/timestampt()), for 7.1 it fixing Y,YY,YYY,YYYY conversion, the docs and regress tests update are included too. During the patch testing I found small bug in miscadmin.h in convertstr() declaration. Here it's fixed too. Thanks Karel
2000-11-25 06:00:33 +01: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');
Adjust our timezone library to use pg_time_t (typedef'd as int64) in place of time_t, as per prior discussion. The behavior does not change on machines without a 64-bit-int type, but on machines with one, which is most, we are rid of the bizarre boundary behavior at the edges of the 32-bit-time_t range (1901 and 2038). The system will now treat times over the full supported timestamp range as being in your local time zone. It may seem a little bizarre to consider that times in 4000 BC are PST or EST, but this is surely at least as reasonable as propagating Gregorian calendar rules back that far. I did not modify the format of the zic timezone database files, which means that for the moment the system will not know about daylight-savings periods outside the range 1901-2038. Given the way the files are set up, it's not a simple decision like 'widen to 64 bits'; we have to actually think about the range of years that need to be supported. We should probably inquire what the plans of the upstream zic people are before making any decisions of our own.
2004-06-03 04:08:07 +02:00
to_timestamp_11 | to_timestamp
-----------------+-------------------------------
| Thu Nov 16 00:00:00 20000 PST
here is a patch for formatting.c (to_char/timestampt()), for 7.1 it fixing Y,YY,YYY,YYYY conversion, the docs and regress tests update are included too. During the patch testing I found small bug in miscadmin.h in convertstr() declaration. Here it's fixed too. Thanks Karel
2000-11-25 06:00:33 +01:00
(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)
Add two new format fields for use with to_char(), to_date() and to_timestamp(): - ID for day-of-week - IDDD for day-of-year This makes it possible to convert ISO week dates to and from text fully represented in either week ('IYYY-IW-ID') or day-of-year ('IYYY-IDDD') format. I have also added an 'isoyear' field for use with extract / date_part. Brendan Jurd
2007-02-16 04:39:46 +01:00
SELECT '' AS to_timestamp_15, to_timestamp('2005426', 'YYYYWWD');
to_timestamp_15 | to_timestamp
-----------------+------------------------------
| Sat Oct 15 00:00:00 2005 PDT
(1 row)
SELECT '' AS to_timestamp_16, to_timestamp('2005300', 'YYYYDDD');
to_timestamp_16 | to_timestamp
-----------------+------------------------------
| Thu Oct 27 00:00:00 2005 PDT
(1 row)
SELECT '' AS to_timestamp_17, to_timestamp('2005527', 'IYYYIWID');
to_timestamp_17 | to_timestamp
-----------------+------------------------------
| Sun Jan 01 00:00:00 2006 PST
(1 row)
SELECT '' AS to_timestamp_18, to_timestamp('005527', 'IYYIWID');
to_timestamp_18 | to_timestamp
-----------------+------------------------------
| Sun Jan 01 00:00:00 2006 PST
(1 row)
SELECT '' AS to_timestamp_19, to_timestamp('05527', 'IYIWID');
to_timestamp_19 | to_timestamp
-----------------+------------------------------
| Sun Jan 01 00:00:00 2006 PST
(1 row)
SELECT '' AS to_timestamp_20, to_timestamp('5527', 'IIWID');
to_timestamp_20 | to_timestamp
-----------------+------------------------------
| Sun Jan 01 00:00:00 2006 PST
(1 row)
SELECT '' AS to_timestamp_21, to_timestamp('2005364', 'IYYYIDDD');
to_timestamp_21 | to_timestamp
-----------------+------------------------------
| Sun Jan 01 00:00:00 2006 PST
(1 row)
Add check of 'SET DateStyle TO DEFAULT'.
2000-09-22 17:33:31 +02:00
SET DateStyle TO DEFAULT;