aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/date.c
Commit message (Collapse)AuthorAge
* Update copyrights for 2013Bruce Momjian2013-01-01
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-10
| | | | commit-fest.
* Expand the allowed range of timezone offsets to +/-15:59:59 from Greenwich.Tom Lane2012-05-30
| | | | | | | | | | | | | | | We used to only allow offsets less than +/-13 hours, then it was +/14, then it was +/-15. That's still not good enough though, as per today's bug report from Patric Bechtel. This time I actually looked through the Olson timezone database to find the largest offsets used anywhere. The winners are Asia/Manila, at -15:56:00 until 1844, and America/Metlakatla, at +15:13:42 until 1867. So we'd better allow offsets less than +/-16 hours. Given the history, we are way overdue to have some greppable #define symbols controlling this, so make some ... and also remove an obsolete comment that didn't get fixed the last time. Back-patch to all supported branches.
* Remove unused tzn arguments for timestamp2tm()Peter Eisentraut2012-03-15
|
* Improve EncodeDateTime and EncodeTimeOnly APIsPeter Eisentraut2012-03-14
| | | | | Use an explicit argument to tell whether to include the time zone in the output, rather than using some undocumented pointer magic.
* Add transform functions for various temporal typmod coercisions.Robert Haas2012-02-08
| | | | | | This enables ALTER TABLE to skip table and index rebuilds in some cases. Noah Misch, with trivial changes by me.
* Update copyright notices for year 2012.Bruce Momjian2012-01-01
|
* Create a "sort support" interface API for faster sorting.Tom Lane2011-12-07
| | | | | | | | | | | | This patch creates an API whereby a btree index opclass can optionally provide non-SQL-callable support functions for sorting. In the initial patch, we only use this to provide a directly-callable comparator function, which can be invoked with a bit less overhead than the traditional SQL-callable comparator. While that should be of value in itself, the real reason for doing this is to provide a datatype-extensible framework for more aggressive optimizations, as in Peter Geoghegan's recent work. Robert Haas and Tom Lane
* Support range data types.Heikki Linnakangas2011-11-03
| | | | | | | Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
* Move Timestamp/Interval typedefs and basic macros into datatype/timestamp.h.Tom Lane2011-09-09
| | | | | | | | | | | As per my recent proposal, this refactors things so that these typedefs and macros are available in a header that can be included in frontend-ish code. I also changed various headers that were undesirably including utils/timestamp.h to include datatype/timestamp.h instead. Unsurprisingly, this showed that half the system was getting utils/timestamp.h by way of xlog.h. No actual code changes here, just header refactoring.
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-10
|
* Use macros for time-based constants, rather than constants.Bruce Momjian2011-03-12
|
* Stamp copyrights for year 2011.Bruce Momjian2011-01-01
|
* Avoid unexpected conversion overflow in planner for distant date values.Tom Lane2010-12-28
| | | | | | | | | | | | | | The "date" type supports a wider range of dates than int64 timestamps do. However, there is pre-int64-timestamp code in the planner that assumes that all date values can be converted to timestamp with impunity. Fortunately, what we really need out of the conversion is always a double (float8) value; so even when the date is out of timestamp's range it's possible to produce a sane answer. All we need is a code path that doesn't try to force the result into int64. Per trouble report from David Rericha. Back-patch to all supported versions. Although this is surely a corner case, there's not much point in advertising a date range wider than timestamp's if we will choke on such values in unexpected places.
* Remove cvs keywords from all files.Magnus Hagander2010-09-20
|
* pgindent run for 9.0Bruce Momjian2010-02-26
|
* date_recv should accept infinities.Itagaki Takahiro2010-02-18
| | | | Reported by James William Pye.
* Update copyright for the year 2010.Bruce Momjian2010-01-02
|
* Fix range check in date_recv that tried to limit accepted values to onlyHeikki Linnakangas2009-10-26
| | | | | | | | | | | those accepted by date_in(). I confused julian day numbers and number of days since the postgres epoch 2000-01-01 in the original patch. I just noticed that it's still easy to get such out-of-range values into the database using to_date or +- operators, but this patch doesn't do anything about those functions. Per report from James Pye.
* Tigthen binary receive functions so that they reject values that the textHeikki Linnakangas2009-09-04
| | | | | | | | | input functions don't accept either. While the backend can handle such values fine, they can cause trouble in clients and in pg_dump/restore. This is followup to the original issue on time datatype reported by Andrew McNamara a while ago. Like that one, none of these seem worth back-patching.
* Fix time_part and timetz_part (ie, EXTRACT() for those datatypes) toTom Lane2009-07-29
| | | | | | | | | | | | | | | | include a fractional part in the output for MILLISECOND and SECOND cases, rather than truncating the source value. This is what the float-timestamp code has always done, and it was clearly the code author's intent to do the same for integer timestamps, but he forgot about integer division in C. The other datatypes supported by EXTRACT() already do this correctly. Backpatch to 8.4, so that the default (integer) behavior of that branch will match the default (float) behavior of older branches. Arguably we should patch further back, but it's possible that applications are expecting the broken behavior in older branches. 8.4 is new enough that expectations shouldn't be too settled. Per report from Greg Stark.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Add range checks to time_recv() and timetz_recv(), to prevent binary inputTom Lane2009-05-26
| | | | | | | | of time values that would not be accepted via textual input. Per gripe from Andrew McNamara. This is potentially a back-patchable bug fix, but for the moment it doesn't seem sufficiently high impact to justify doing that.
* Update copyright for 2009.Bruce Momjian2009-01-01
|
* Extend the date type to support infinity and -infinity, analogously toTom Lane2008-10-14
| | | | | | | the timestamp types. Turns out this doesn't even reduce the available range of dates, since the restriction to dates that work for Julian-date arithmetic is much tighter than the int32 range anyway. Per a longstanding TODO item.
* Fix AT TIME ZONE (in all three variants) so that we first try to interpretTom Lane2008-07-07
| | | | | | | | | | | | | | | | the timezone argument as a timezone abbreviation, and only try it as a full timezone name if that fails. The zic database has four zones (CET, EET, MET, WET) that are full daylight-savings zones and yet have names that are the same as their abbreviations for standard time, resulting in ambiguity. In the timestamp input functions we resolve the ambiguity by preferring the abbreviation, and AT TIME ZONE should work the same way. (No functionality is lost because the zic database also has other names for these zones, eg Europe/Zurich.) Per gripe from Jaromir Talir. Backpatch to 8.1. Older releases did not have the issue because AT TIME ZONE only accepted abbreviations not zone names. (Thus, this patch also arguably fixes a compatibility botch introduced at 8.1: in ambiguous cases we now behave the same as 8.0 did.)
* Simplify and standardize conversions between TEXT datums and ordinary CTom Lane2008-03-25
| | | | | | | | | | | | | | | | | | | | strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
* Get rid of a bunch of #ifdef HAVE_INT64_TIMESTAMP conditionals by inventingTom Lane2008-03-21
| | | | | | | | | | a new typedef TimeOffset to represent an intermediate time value. It's either int64 or double as appropriate, and in most usages will be measured in microseconds or seconds the same as Timestamp. We don't call it Timestamp, though, since the value doesn't necessarily represent an absolute time instant. Warren Turkal
* Replace time_t with pg_time_t (same values, but always int64) in on-diskTom Lane2008-02-17
| | | | | | | | | | | | | | data structures and backend internal APIs. This solves problems we've seen recently with inconsistent layout of pg_control between machines that have 32-bit time_t and those that have already migrated to 64-bit time_t. Also, we can get out from under the problem that Windows' Unix-API emulation is not consistent about the width of time_t. There are a few remaining places where local time_t variables are used to hold the current or recent result of time(NULL). I didn't bother changing these since they do not affect any cross-module APIs and surely all platforms will have 64-bit time_t before overflow becomes an actual risk. time_t should be avoided for anything visible to extension modules, however.
* Update copyrights in source tree to 2008.Bruce Momjian2008-01-01
|
* pgindent run for 8.3.Bruce Momjian2007-11-15
|
* In the integer-datetimes case, date2timestamp and date2timestamptz needTom Lane2007-09-26
| | | | | to check for overflow because the legal range of type date is actually wider than timestamp's. Problem found by Neil Conway.
* Switch over to using the src/timezone functions for formatting timestampsTom Lane2007-08-04
| | | | | | | | | | | | | | displayed in the postmaster log. This avoids Windows-specific problems with localized time zone names that are in the wrong encoding, and generally seems like a good idea to forestall other potential platform-dependent issues. To preserve the existing behavior that all backends will log in the same time zone, create a new GUC variable log_timezone that can only be changed on a system-wide basis, and reference log-related calculations to that zone instead of the TimeZone variable. This fixes the issue reported by Hiroshi Saito that timestamps printed by xlog.c startup could be improperly localized on Windows. We still need a simpler patch for that problem in the back branches, however.
* Fix up hash functions for datetime datatypes so that they don't takeTom Lane2007-07-06
| | | | | | unwarranted liberties with int8 vs float8 values for these types. Specifically, be sure to apply either hashint8 or hashfloat8 depending on HAVE_INT64_TIMESTAMP. Per my gripe of even date.
* Tweak the API for per-datatype typmodin functions so that they are passedTom Lane2007-06-15
| | | | | | | | | | | | an array of strings rather than an array of integers, and allow any simple constant or identifier to be used in typmods; for example create table foo (f1 widget(42,'23skidoo',point)); Of course the typmodin function has still got to pack this info into a non-negative int32 for storage, but it's still a useful improvement in flexibility, especially considering that you can do nearly anything if you are willing to keep the info in a side table. We can get away with this change since we have not yet released a version providing user-definable typmods. Per discussion.
* Downgrade implicit casts to text to be assignment-only, except for the onesTom Lane2007-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
* Fix erroneous error reporting for overlength input in text_date(),Tom Lane2007-06-02
| | | | text_time(), and text_timetz(). 7.4-vintage bug found by Greg Stark.
* Tweak: use memcpy() in text_time(), rather than manually copying bytesNeil Conway2007-05-30
| | | | in a loop.
* Replace direct assignments to VARATT_SIZEP(x) with SET_VARSIZE(x, len).Tom Lane2007-02-27
| | | | | | | | | | | Get rid of VARATT_SIZE and VARATT_DATA, which were simply redundant with VARSIZE and VARDATA, and as a consequence almost no code was using the longer names. Rename the length fields of struct varlena and various derived structures to catch anyplace that was accessing them directly; and clean up various places so caught. In itself this patch doesn't change any behavior at all, but it is necessary infrastructure if we hope to play any games with the representation of varlena headers. Greg Stark and Tom Lane
* Add two new format fields for use with to_char(), to_date() andBruce Momjian2007-02-16
| | | | | | | | | | | | | | 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
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-05
| | | | back-stamped for this.
* Support type modifiers for user-defined types, and pull most knowledgeTom Lane2006-12-30
| | | | | | about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-14
|
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-05
|
* Reject out-of-range dates in date_in().Tom Lane2006-02-09
| | | | Kris Jurka
* Standard pgindent run for 8.1.Bruce Momjian2005-10-15
|
* Fix (hopefully for the last time) problems with datetime values displayingTom Lane2005-10-09
| | | | | | | like '23:59:60' because of fractional-second roundoff problems. Trying to control this upstream of the actual display code was hopeless; the right way is to explicitly round fractional seconds in the display code and then refigure the results if the fraction rounds up to 1. Per bug #1927.
* Fix the various forms of AT TIME ZONE to accept either timezones foundTom Lane2005-09-09
| | | | | | | | | in the zic database or zone names found in the date token table. This preserves the old ability to do AT TIME ZONE 'PST' along with the new ability to do AT TIME ZONE 'PST8PDT'. Per gripe from Bricklen Anderson. Also, fix some inconsistencies in usage of TZ_STRLEN_MAX --- the old code had the potential for one-byte buffer overruns, though given alignment considerations it's unlikely there was any real risk.
* Andrew pointed out that the current fix didn't handle dates that wereBruce Momjian2005-07-23
| | | | | | | | | | | 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)
* More minor spacing improvements.Bruce Momjian2005-07-22
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 22:40:30 +0000