summaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/datetime.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Use macros for time-based constants, rather than constants.Bruce Momjian2011-03-121-23/+26
|
* Stamp copyrights for year 2011.Bruce Momjian2011-01-011-1/+1
|
* Re-allow input of Julian dates prior to 0001-01-01 AD.Tom Lane2010-09-221-12/+25
| | | | | | This was unintentionally broken in 8.4 while tightening up checking of ordinary non-Julian date inputs to forbid references to "year zero". Per bug #5672 from Benjamin Gigot.
* Remove cvs keywords from all files.Magnus Hagander2010-09-201-1/+1
|
* Fix an ancient typo that prevented the detection of conflicting fields whenTom Lane2010-08-021-2/+2
| | | | | | | | interval input "invalid" was specified together with other fields. Spotted by Neil Conway with the help of a clang warning. Although this has been wrong since the interval code was written more than 10 years ago, it doesn't affect anything beyond which error message you get for a wrong input, so not worth back-patching very far.
* Adjust comments about avoiding use of printf's %.*s.Tom Lane2010-05-091-6/+4
| | | | | | | | | | | My initial impression that glibc was measuring the precision in characters (which is what the Linux man page says it does) was incorrect. It does take the precision to be in bytes, but it also tries to truncate the string at a character boundary. The bottom line remains the same: it will mess up if the string is not in the encoding it expects, so we need to avoid %.*s anytime there's a significant risk of that. Previous code changes are still good, but adjust the comments to reflect this knowledge. Per research by Hernan Gonzalez.
* Work around a subtle portability problem in use of printf %s format.Tom Lane2010-05-081-1/+10
| | | | | | | | | | | | | Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
* Update copyright for the year 2010.Bruce Momjian2010-01-021-2/+2
|
* Fix overflow for INTERVAL 'x ms' where x is more than a couple million,Tom Lane2009-08-181-1/+4
| | | | | | | and integer datetimes are in use. Per bug report from Hubert Depesz Lubaczewski. Alex Hunsaker
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-118/+120
| | | | provided by Andrew.
* Make handling of INTERVAL DAY TO MINUTE and INTERVAL DAY TO SECOND inputTom Lane2009-06-101-4/+4
| | | | | | | | | | | | more consistent with other cases, by having an unlabeled integer field be treated as a number of minutes or seconds respectively. These cases are outside the spec (which insists on full "dd hh:mm" or "dd hh:mm:ss" input respectively), so it's not much help to us in deciding what to do. But with this change, it's uniformly the case that an unlabeled integer will be considered as being a number of the interval's rightmost field. The change also takes us back to the 8.3 behavior of throwing error for certain ambiguous inputs such as INTERVAL '1 2' DAY TO MINUTE. Per recent discussion.
* Fix DecodeInterval to report an error for multiple occurrences of DAY, WEEK,Tom Lane2009-06-011-8/+8
| | | | | | | | | | | YEAR, DECADE, CENTURY, or MILLENIUM fields, just as it always has done for other types of fields. The previous behavior seems to have been a hack to avoid defining bit-positions for all these field types in DTK_M() masks, rather than something that was really considered to be desired behavior. But there is room in the masks for these, and we really need to tighten up at least the behavior of DAY and YEAR fields to avoid unexpected behavior associated with the 8.4 changes to interpret ambiguous fields based on the interval qualifier (typmod) value. Per my example and proposed patch.
* Remove the useless and rather inconsistent return values of EncodeDateOnly,Tom Lane2009-05-261-25/+9
| | | | | EncodeTimeOnly, EncodeDateTime, EncodeInterval. These don't have any good reason to fail, and their callers were mostly not checking anyway.
* When checking for datetime field overflow, we should allow a fractional-secondTom Lane2009-05-011-11/+10
| | | | | | | | | | | | | | part that rounds up to exactly 1.0 second. The previous coding rejected input like "00:12:57.9999999999999999999999999999", with the exact number of nines needed to cause failure varying depending on float-timestamp option and possibly on platform. Obviously this should round up to the next integral second, if we don't have enough precision to distinguish the value from that. Per bug #4789 from Robert Kruus. In passing, fix a missed check for fractional seconds in one copy of the "is it greater than 24:00:00" code. Broken all the way back, so patch all the way back.
* Remove the datetime keywords ABSTIME and RELTIME, which we'd been treating asTom Lane2009-03-221-3/+1
| | | | | | | | noise words for the last twelve years, for compatibility with Berkeley-era output formatting of the special INVALID values for those datatypes. Considering that the datatypes themselves have been deprecated for awhile, this is taking backwards compatibility a little far. Per gripe from Josh Berkus.
* Improve zero-year comments.Bruce Momjian2009-03-171-2/+2
|
* Document that datetime year '0' is considered in a recent century, notBruce Momjian2009-03-171-2/+2
| | | | just '00'.
* Update copyright for 2009.Bruce Momjian2009-01-011-2/+2
|
* Clean up the ancient decision to show only two fractional-seconds digitsTom Lane2008-11-121-546/+298
| | | | | | | | | | | | | in "postgres_verbose" intervalstyle, and the equally arbitrary decision to show at least two fractional-seconds digits in most other datetime display styles. This results in some minor changes in the expected regression test outputs. Also, coalesce a lot of repetitive code in datetime.c into subroutines, for clarity and ease of maintenance. In particular this roughly halves the number of #ifdef HAVE_INT64_TIMESTAMP segments. Ron Mayer, with some additional kibitzing from Tom Lane
* Add support for input and output of interval values formatted per ISO 8601;Tom Lane2008-11-111-14/+356
| | | | | | | | specifically, we can input either the "format with designators" or the "alternative format", and we can output the former when IntervalStyle is set to iso_8601. Ron Mayer
* Add a new GUC variable called "IntervalStyle" that decouples interval outputTom Lane2008-11-091-44/+200
| | | | | | | | | | from DateStyle, and create a new interval style that produces output matching the SQL standard (at least for interval values that fall within the standard's restrictions). IntervalStyle is also used to resolve the conflict between the standard and traditional Postgres rules for interpreting negative interval input. Ron Mayer
* Fix recently added code for SQL years-months interval syntax so thatTom Lane2008-11-081-2/+2
| | | | | it behaves correctly for a leading minus sign, zero year value, and nonzero month value. Per discussion with Ron Mayer.
* Fix improper display of fractional seconds in interval valuesTom Lane2008-10-021-2/+2
| | | | | | when using --enable-integer-datetimes and a non-ISO datestyle. Ron Mayer
* Fix integral timestamps so the output is consistent in all cases toBruce Momjian2008-09-241-9/+9
| | | | | | | | | round: select interval '0:0:0.7', interval '@ 0.70 secs', interval '0.7 seconds'; Ron Mayer
* Clean up a couple of weird corner cases in interval parsing: make -yyyy-mm beTom Lane2008-09-161-31/+13
| | | | | | | | | interpreted as expected (the sign should affect months too), and get rid of hard-wired assumption that unmarked signed values must be hours (if integers) or seconds (if floats). The former was just a bug in my previous patch, while the latter may have made sense at one time but seems illogical now that we support determination of the units from typmod information. Ron Mayer and myself.
* Adjust the parser to accept the typename syntax INTERVAL ... SECOND(n)Tom Lane2008-09-111-4/+22
| | | | | | | | | | | | | | | | | | | and the literal syntax INTERVAL 'string' ... SECOND(n), as required by the SQL standard. Our old syntax put (n) directly after INTERVAL, which was a mistake, but will still be accepted for backward compatibility as well as symmetry with the TIMESTAMP cases. Change intervaltypmodout to show it in the spec's way, too. (This could potentially affect clients, if there are any that analyze the typmod of an INTERVAL in any detail.) Also fix interval input to handle 'min:sec.frac' properly; I had overlooked this case in my previous patch. Document the use of the interval fields qualifier, which up to now we had never mentioned in the docs. (I think the omission was intentional because it didn't work per spec; but it does now, or at least close enough to be credible.)
* Make our parsing of INTERVAL literals spec-compliant (or at least a heck ofTom Lane2008-09-101-12/+73
| | | | | | | | | | | | | | | a lot closer than it was before). To do this, tweak coerce_type() to pass through the typmod information when invoking interval_in() on an UNKNOWN constant; then fix DecodeInterval to pay attention to the typmod when deciding how to interpret a units-less integer value. I changed one or two other details as well. I believe the code now reacts as expected by spec for all the literal syntaxes that are specifically enumerated in the spec. There are corner cases involving strings that don't exactly match the set of fields called out by the typmod, for which we might want to tweak the behavior some more; but I think this is an area of user friendliness rather than spec compliance. There remain some non-compliant details about the SQL syntax (as opposed to what's inside the literal string); but at least we'll throw error rather than silently doing the wrong thing in those cases.
* Fix datetime input functions to correctly detect integer overflow whenTom Lane2008-06-091-12/+29
| | | | | running on a 64-bit platform ... strtol() will happily return 64-bit output in that case. Per bug #4231 from Geoff Tolley.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-121-2/+1
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
* Simplify and standardize conversions between TEXT datums and ordinary CTom Lane2008-03-251-7/+4
| | | | | | | | | | | | | | | | | | | | 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
* Reject year zero during datetime input, except when it's a 2-digit yearTom Lane2008-02-251-9/+15
| | | | | | | (then it means 2000 AD). Formerly we silently interpreted this as 1 BC, which at best is unwarranted familiarity with the implementation. It's barely possible that some app somewhere expects the old behavior, though, so we won't back-patch this into existing release branches.
* Fix datetime input to behave correctly for Feb 29 in years BC.Tom Lane2008-02-251-99/+93
| | | | | | | | | | | | | | | | | | | Formerly, DecodeDate attempted to verify the day-of-the-month exactly, but it was under the misapprehension that it would know whether we were looking at a BC year or not. In reality this check can't be made until the calling function (eg DecodeDateTime) has processed all the fields. So, split the BC adjustment and validity checks out into a new function ValidateDate that is called only after processing all the fields. In passing, this patch makes DecodeTimeOnly work for BC inputs, which it never did before. (The historical veracity of all this is nonexistent, of course, but if we're going to say we support proleptic Gregorian calendar then we should do it correctly. In any case the unpatched code is broken because it could emit dates that it would then reject on re-inputting.) Per report from Bernd Helmle. Back-patch as far as 8.0; in 7.x we were not using our own calendar support and so this seems a bit too risky to put into 7.4.
* Replace time_t with pg_time_t (same values, but always int64) in on-diskTom Lane2008-02-171-4/+6
| | | | | | | | | | | | | | 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-011-2/+2
|
* pgindent run for 8.3.Bruce Momjian2007-11-151-25/+26
|
* Switch over to using the src/timezone functions for formatting timestampsTom Lane2007-08-041-4/+4
| | | | | | | | | | | | | | 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 DecodeDateTime to allow timezone to appear before year. This hadTom Lane2007-06-121-4/+10
| | | | | | historically worked in some but not all cases, but as of 8.2 it failed for all timezone formats. Fix, and add regression test cases to catch future regressions in this area. Per gripe from Adam Witney.
* Fix a bug in input processing for the "interval" type. Previously,Neil Conway2007-05-291-2/+14
| | | | | | | | "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
* Code cleanup: use "bool" for Boolean variables, rather than "int".Neil Conway2007-05-271-15/+15
|
* Fix date/time formats for XML Schema output.Peter Eisentraut2007-03-011-9/+18
| | | | Pavel Stehule
* Add "isodow" option to EXTRACT() and date_part() where Sunday = 7.Bruce Momjian2007-02-191-1/+2
|
* Add two new format fields for use with to_char(), to_date() andBruce Momjian2007-02-161-1/+2
| | | | | | | | | | | | | | 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-051-2/+2
| | | | back-stamped for this.
* Fix up timetz input so that a date is required only when the specifiedTom Lane2006-10-181-6/+40
| | | | | | | | 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.
* Fix up some problems in handling of zic-style time zone names in datetimeTom Lane2006-10-171-227/+151
| | | | | | | | | | | | | | 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.
* pgindent run for 8.2.Bruce Momjian2006-10-041-48/+58
|
* Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs,Tom Lane2006-09-161-7/+118
| | | | | | 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.
* Fix interval input parser so that fractional weeks and months areTom Lane2006-09-041-15/+29
| | | | | | | cascaded first to days and only what is leftover into seconds. This seems to satisfy the principle of least surprise given the general conversion to three-part interval values --- it was an oversight that these cases weren't dealt with in 8.1. Michael Glaesemann
* Remove hard-wired lists of timezone abbreviations in favor of providingTom Lane2006-07-251-390/+168
| | | | | | | | | 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.
* Fix a passel of recently-committed violations of the rule 'thou shaltTom Lane2006-07-141-2/+1
| | | | | have no other gods before c.h'. Also remove some demonstrably redundant #include lines, mostly of <errno.h> which was added to c.h years ago.
View Lorry Controller Status