- 07 Nov, 2007 1 commit
-
-
Peter Eisentraut authored
-
- 12 Jun, 2007 1 commit
-
-
Tom Lane authored
-
- 29 May, 2007 1 commit
-
-
Neil Conway authored
"microsecond" and "millisecond" units were not considered valid input by themselves, which caused inputs like "1 millisecond" to be rejected erroneously. Update the docs, add regression tests, and backport to 8.2 and 8.1
-
- 19 Feb, 2007 1 commit
-
-
Bruce Momjian authored
-
- 16 Feb, 2007 1 commit
-
-
Bruce Momjian authored
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
-
- 05 Jan, 2007 1 commit
-
-
Bruce Momjian authored
back-stamped for this.
-
- 18 Oct, 2006 1 commit
-
-
Tom Lane authored
timezone actually has a daylight-savings rule. This avoids breaking cases that used to work because they went through the DecodePosixTimezone code path. Per contrib regression failures (mea culpa for not running those yesterday...). Also document the already-applied change to allow GMT offsets up to 14 hours.
-
- 16 Sep, 2006 1 commit
-
-
Tom Lane authored
and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
-
- 25 Jul, 2006 1 commit
-
-
Tom Lane authored
configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
-
- 06 Jun, 2006 1 commit
-
-
Bruce Momjian authored
-
- 05 Mar, 2006 1 commit
-
-
Bruce Momjian authored
-
- 15 Oct, 2005 1 commit
-
-
Bruce Momjian authored
-
- 23 Jul, 2005 1 commit
-
-
Bruce Momjian authored
near daylight savings time boudaries. This handles it properly, e.g. test=> select '2005-04-03 04:00:00'::timestamp at time zone 'America/Los_Angeles'; timezone ------------------------ 2005-04-03 07:00:00-04 (1 row)
-
- 22 Jul, 2005 1 commit
-
-
Bruce Momjian authored
-
- 26 May, 2005 1 commit
-
-
Neil Conway authored
working buffer into ParseDateTime() and reject too-long input there, rather than checking the length of the input string before calling ParseDateTime(). The old method was bogus because ParseDateTime() can use a variable amount of working space, depending on the content of the input string (e.g. how many fields need to be NUL terminated). This fixes a minor stack overrun -- I don't _think_ it's exploitable, although I won't claim to be an expert. Along the way, fix a bug reported by Mark Dilger: the working buffer allocated by interval_in() was too short, which resulted in rejecting some perfectly valid interval input values. I added a regression test for this fix.
-
- 24 May, 2005 1 commit
-
-
Bruce Momjian authored
-
- 31 Dec, 2004 1 commit
-
-
PostgreSQL Daemon authored
Tag appropriate files for rc3 Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
-
- 29 Aug, 2004 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 03 Jun, 2004 1 commit
-
-
Tom Lane authored
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.
-
- 21 May, 2004 1 commit
-
-
Tom Lane authored
and should do now that we control our own destiny for timezone handling, but this commit gets the bulk of the picayune diffs in place. Magnus Hagander and Tom Lane.
-
- 19 Jan, 2004 1 commit
-
-
Tom Lane authored
should not be too eager to reject paths involving unknown schemas, since it can't really tell whether the schemas exist in the target database. (Also, when reading pg_dumpall output, it could be that the schemas don't exist yet, but eventually will.) ALTER USER SET has a similar issue. So, reduce the normal ERROR to a NOTICE when checking search_path values for these commands. Supporting this requires changing the API for GUC assign_hook functions, which causes the patch to touch a lot of places, but the changes are conceptually trivial.
-
- 29 Nov, 2003 1 commit
-
-
PostgreSQL Daemon authored
make sure the $Id tags are converted to $PostgreSQL as well ...
-
- 27 Aug, 2003 1 commit
-
-
Tom Lane authored
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.
-
- 05 Aug, 2003 1 commit
-
-
Tom Lane authored
writing one more value into return arrays than will fit. This is potentially a stack smash, though I do not think it is a problem in current uses of the routine, since a failure return causes elog anyway.
-
- 04 Aug, 2003 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 17 Jul, 2003 2 commits
-
-
Tom Lane authored
date2j(). This ensures we give reasonable errors instead of bizarre behavior for input dates far in the future.
-
Tom Lane authored
for the sign of timezone offsets, ie, positive is east from UTC. These were previously out of step with other operations that accept or show timezones, such as I/O of timestamptz values.
-
- 18 May, 2003 1 commit
-
-
Tom Lane authored
Ross Reedstrom, a couple months back) and to detect timezones that are using leap-second timekeeping. The unknown-zone-name test is pretty heuristic and ugly, but it seems better than the old behavior of just switching to GMT given a bad name. Also make DecodePosixTimezone() a tad more robust.
-
- 18 Apr, 2003 1 commit
-
-
Bruce Momjian authored
-
- 04 Apr, 2003 1 commit
-
-
Tom Lane authored
date2j(2000, 1, 1). Should make for some marginal speed improvement in date/time operations.
-
- 20 Feb, 2003 1 commit
-
-
Tom Lane authored
answer when SET TIMEZONE has been done since the start of the current transaction. Per bug report from Robert Haas. I plan some futher cleanup in HEAD, but this is a low-risk patch for the immediate issue in 7.3.
-
- 19 Feb, 2003 1 commit
-
-
Bruce Momjian authored
functions which limited the maximum date for a timestamp to AD 1465001. The new limit is AD 5874897. The files affected are: doc/src/sgml/datatype.sgml: Documentation change due to patch. Included is a notice about the reduced range when using an eight-byte integer for timestamps. src/backend/utils/adt/datetime.c: Replacement functions for j2date() and date2j() functions. src/include/utils/datetime.h: Corrected a bug with the limit on the earliest possible date, Nov 23,-4713 has a Julian day count of -1. The earliest possible date should be Nov 24, -4713 with a day count of 0. src/test/regress/expected/horology-no-DST-before-1970.out: src/test/regress/expected/horology-solaris-1947.out: src/test/regress/expected/horology.out: Copies of expected output for regression testing. Note: Only horology.out has been physically tested. I do not have access to a Solaris box and I don't know how to provoke the "pre-1970" test. src/test/regress/sql/horology.sql: Added some test cases to check extended range. John Cochran
-
- 16 Jan, 2003 1 commit
-
-
Tom Lane authored
datetime token tables. Even more embarrassing, the regression tests revealed some of the problems --- but evidently the bogus output wasn't questioned. Add code to postmaster startup to directly check the tables for correct ordering, in hopes of not being embarrassed like this again.
-
- 04 Sep, 2002 1 commit
-
-
Bruce Momjian authored
-
- 20 Jun, 2002 1 commit
-
-
Bruce Momjian authored
-
- 11 Jun, 2002 1 commit
-
-
Jan Wieck authored
> Changes to avoid collisions with WIN32 & MFC names... > 1. Renamed: > a. PROC => PGPROC > b. GetUserName() => GetUserNameFromId() > c. GetCurrentTime() => GetCurrentDateTime() > d. IGNORE => IGNORE_DTF in include/utils/datetime.h & utils/adt/datetim > > 2. Added _P to some lex/yacc tokens: > CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT Jan
-
- 17 May, 2002 1 commit
-
-
Tom Lane authored
GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
-
- 21 Apr, 2002 1 commit
-
-
Thomas G. Lockhart authored
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.
-