aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/datetime.c
Commit message (Collapse)AuthorAge
* Fix mis-display of negative fractional seconds in interval values forTom Lane2005-04-20
| | | | --enable-integer-datetimes case. Per report from Oliver Siegmar.
* Attached patch gets rid of the global timezone in the following steps:Bruce Momjian2005-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * Changes the APIs to the timezone functions to take a pg_tz pointer as an argument, representing the timezone to use for the selected operation. * Adds a global_timezone variable that represents the current timezone in the backend as set by SET TIMEZONE (or guc, or env, etc). * Implements a hash-table cache of loaded tables, so we don't have to read and parse the TZ file everytime we change a timezone. While not necesasry now (we don't change timezones very often), I beleive this will be necessary (or at least good) when "multiple timezones in the same query" is eventually implemented. And code-wise, this was the time to do it. There are no user-visible changes at this time. Implementing the "multiple zones in one query" is a later step... This also gets rid of some of the cruft needed to "back out a timezone change", since we previously couldn't check a timezone unless it was activated first. Passes regression tests on win32, linux (slackware 10) and solaris x86. Magnus Hagander
* interval_out failed to mention 'ago' for negative intervals in SQL andTom Lane2005-01-11
| | | | GERMAN datestyles. Ancient bug reported by Terry Lee Tucker.
* Tag appropriate files for rc3PostgreSQL Daemon2004-12-31
| | | | | | | | 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 ...
* Invent pg_next_dst_boundary() and rewrite DetermineLocalTimeZone() toTom Lane2004-11-01
| | | | | | | | | | | | use it, as per my proposal of yesterday. This gives us a means of determining the zone offset to impute to an unlabeled timestamp that is both efficient and reliable, unlike all our previous tries involving mktime() and localtime(). The behavior for invalid or ambiguous times at a DST transition is fixed to be really and truly "assume standard time", fixing a bug that has come and gone repeatedly but was back again in 7.4. (There is some ongoing discussion about whether we should raise an error instead, but for the moment I'll make it do what it was previously intended to do.)
* Another pgindent run with lib typedefs added.Bruce Momjian2004-08-30
|
* Pgindent run for 8.0.Bruce Momjian2004-08-29
|
* Update copyright to 2004.Bruce Momjian2004-08-29
|
* Cause the format of BC timestamptz output to be 'datetime zone BC' ratherTom Lane2004-07-11
| | | | | | | than 'datetime BC zone', because the former is accepted by the timestamptz input converter while the latter may not be depending on spacing. This is not a loss of compatibility w.r.t. 7.4 and before, because until very recently there was never a case where we'd output both zone and 'BC'.
* Adjust our timezone library to use pg_time_t (typedef'd as int64) inTom Lane2004-06-03
| | | | | | | | | | | | | | | | | | | 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.
* Suppress compile warnings on machines where the INT64CONST() decorationTom Lane2004-05-31
| | | | is actually needed. Per Oliver Elphick.
* Integrate src/timezone library for all platforms. There is more we canTom Lane2004-05-21
| | | | | | 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.
* Solve the 'Turkish problem' with undesirable locale behavior for caseTom Lane2004-05-07
| | | | | | | | | | | | | conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
* Fix to_char for 1 BC. Previously it returned 1 AD.Bruce Momjian2004-03-30
| | | | | | | Fix to_char(year) for BC dates. Previously it returned one less than the current year. Add documentation mentioning that there is no 0 AD.
* For application to HEAD, following community review.Bruce Momjian2004-02-25
| | | | | | | | | | | | | | * Changes incorrect CYGWIN defines to __CYGWIN__ * Some localtime returns NULL checks (when unchecked cause SEGVs under Win32 regression tests) * Rationalized CreateSharedMemoryAndSemaphores and AttachSharedMemoryAndSemaphores (Bruce, I finally remembered to do it); requires attention. Claudio Natoli
* Repair problem identified by Olivier Prenant: ALTER DATABASE SET search_pathTom Lane2004-01-19
| | | | | | | | | | | 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.
* Back out:Bruce Momjian2003-12-21
| | | | | | | > Attached is a patch that addressed all the discussed issues > that did not break backward compatability, including the > ability to output ISO-8601 compliant intervals by setting > datestyle to iso8601basic.
* In my mind there were two categories of open issuesBruce Momjian2003-12-20
| | | | | | | | | | | | | | | | | | | | | | | | a) ones that are 100% backward (such as the comment about outputting this format) and b) ones that aren't (such as deprecating the current postgresql shorthand of '1Y1M'::interval = 1 year 1 minute in favor of the ISO-8601 'P1Y1M'::interval = 1 year 1 month. Attached is a patch that addressed all the discussed issues that did not break backward compatability, including the ability to output ISO-8601 compliant intervals by setting datestyle to iso8601basic. Interval values can now be written as ISO 8601 time intervals, using the "Format with time-unit designators". This format always starts with the character 'P', followed by a string of values followed by single character time-unit designators. A 'T' separates the date and time parts of the interval. Ron Mayer
* Fix DecodeInterval to handle '-0.1' sanely, per gripe from Tilo Schwarz.Tom Lane2003-12-17
|
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-29
|
* Fix datetime input parsing to accept YYYY-MONTHNAME-DD and related syntaxes,Tom Lane2003-11-16
| | | | | | which had been unintentionally broken by recent changes to tighten up the DateStyle rules for all-numeric date input. Add documentation and regression tests for this, too.
* Message editing: remove gratuitous variations in message wording, standardizePeter Eisentraut2003-09-25
| | | | | terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
* Okay, I've had it with mktime() bugs. While chasing Torello Querci'sTom Lane2003-09-13
| | | | | | | | recent gripe, I discovered not one but two undocumented, undesirable behaviors of glibc's mktime. So, stop using it entirely, and always rely on inversion of localtime() to determine the local time zone. It's not even very much slower, as it turns out that mktime (at least in the glibc implementation) also does repeated reverse-conversions.
* Adjust date/time input parsing code to correctly distinguish the fourTom Lane2003-08-27
| | | | | | | 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.
* Add the Brazilian time zone abbreviations BRT, BRST, FNT, FNST.Tom Lane2003-08-25
| | | | | ACT and ACST were already present. AMT and AMST conflict with the existing entries for Armenia; no change there for the moment.
* Allow parsing of time and timetz inputs to accept the documented inputTom Lane2003-08-25
| | | | | syntax '040506' for '04:05:06', as well as '0405' for '04:05:00'. This has been broken since 7.2 but was only recently complained of.
* Another pgindent run with updated typedefs.Bruce Momjian2003-08-08
|
* Improve documentation of ParseDateTime(). Reorder tests to preventTom Lane2003-08-05
| | | | | | 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.
* Fix several places where fractional-second inputs were misprocessedTom Lane2003-08-05
| | | | | | in HAVE_INT64_TIMESTAMP cases, including two potential stack smashes when more than six fractional digits were supplied. Per bug report from Philipp Reisner.
* Update copyrights to 2003.Bruce Momjian2003-08-04
|
* pgindent run.Bruce Momjian2003-08-04
|
* Apply (a somewhat revised version of) Greg Mullane's patch to eliminateTom Lane2003-07-29
| | | | | | | | | 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.
* Error message editing in utils/adt. Again thanks to Joe Conway for doingTom Lane2003-07-27
| | | | the bulk of the heavy lifting ...
* In ISO datestyle, never emit just HH:MM, always emit HH:MM:SS orTom Lane2003-06-25
| | | | | | | | HH:MM:SS.SSS... when there is a nonzero part-of-a-day field in an interval value. The seconds part used to be suppressed if zero, but there's no equivalent behavior for timestamp, and since we're modeling this format on timestamp it's probably wrong. Per complaint and patch from Larry Rosenman.
* Add code to test for unknown timezone names (following some ideas fromTom Lane2003-05-18
| | | | | | | | 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.
* Allow 60 in seconds fields of timestamp, time, interval input values.Tom Lane2003-05-04
| | | | | | Per recent discussion on pgsql-general, this is appropriate for spec compliance, and has the nice side-effect of easing porting from old pg_dump files that exhibit the 59.999=>60.000 roundoff problem.
* Avoid repeated computation of the constants date2j(1970, 1, 1) andTom Lane2003-04-04
| | | | | date2j(2000, 1, 1). Should make for some marginal speed improvement in date/time operations.
* Simplify timezone-handling code per proposal to pghackers: get rid ofTom Lane2003-02-22
| | | | | | | | setting timezone-related variables during transaction start. They were not used anyway in platforms that HAVE_TM_ZONE or HAVE_INT_TIMEZONE, which it appears is *all* the platforms we are currently supporting. For platforms that have neither, we now only support UTC or numeric- offset-from-UTC timezones.
* Fix timestamptz_in so that parsing of 'now'::timestamptz gives rightTom Lane2003-02-20
| | | | | | | 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.
* The following patches eliminate the overflows in the j2date() and date2j()Bruce Momjian2003-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Repair array subscript overrun identified by Yichen Xie. Reduce theTom Lane2003-01-29
| | | | | | | value of MAX_TIME_PRECISION in floating-point-timestamp-storage case from 13 to 10, which is as much as time_out is actually willing to print. (The alternative of increasing the number of digits we are willing to print looks risky; we might find ourselves printing roundoff garbage.)
* Repair an embarrassingly large number of alphabetization mistakes in theTom Lane2003-01-16
| | | | | | | 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.
* Allow +1300 as a numeric timezone specifier; we already accept FJST as ↵Tom Lane2002-11-13
| | | | meaning +1300.
* pgindent run.Bruce Momjian2002-09-04
|
* Work around mktime() brain damage in recent versions of glibc by usingTom Lane2002-09-03
| | | | | | | a series of localtime() calls to determine the local timezone offset when mktime() fails. This eliminates regression failures on RHL 7.3, and should continue to work until it occurs to the glibc boys to break localtime() as well. By then I hope we'll have our own timezone code...
* Remove sys/types.h in files that include postgres.h, and hence c.h,Bruce Momjian2002-09-02
| | | | because c.h has sys/types.h.
* Add guard code to protect from buffer overruns on long date/time inputThomas G. Lockhart2002-08-04
| | | | | | | | | | | | | | strings. Should go back in and look at doing this a bit more elegantly and (hopefully) cheaper. Probably not too bad anyway, but it seems a shame to scan the strings twice: once for length for this buffer overrun protection, and once to parse the line. Remove use of pow() in date/time handling; was already gone from everything *but* the time data types. Define macros for handling typmod manipulation for date/time types. Should be more robust than all of that brute-force inline code. Rename macros for masking and typmod manipulation to put TIMESTAMP_ or INTERVAL_ in front of the macro name, to reduce the possibility of name space collisions.
* Update copyright to 2002.Bruce Momjian2002-06-20
|
* Katherine Ward wrote:Jan Wieck2002-06-11
| | | | | | | | | | | | | | > 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
* Merge the last few variable.c configuration variables into the genericTom Lane2002-05-17
| | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-05 07:18:36 +0000