summaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/datetime.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Allow timezone names in SQL strings,Bruce Momjian2006-06-071-5/+66
| | | | | | '2006-05-24 21:11 Americas/New_York'::timestamptz Joachim Wieland
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-051-2/+2
|
* Remove comment on errno=0 lines, but add mention to port/strtol.c function.Bruce Momjian2005-12-021-11/+11
|
* Comment "errno = 0" in a more generic way.Bruce Momjian2005-12-011-11/+11
|
* Add comments about why errno is set to zero.Bruce Momjian2005-12-011-11/+11
|
* Check for overflow in strtol() while parsing datetime inputs.Tom Lane2005-12-011-1/+33
| | | | Michael Fuhr.
* Re-run pgindent, fixing a problem where comment lines after a blankBruce Momjian2005-11-221-9/+9
| | | | | | | | | comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
* Standard pgindent run for 8.1.Bruce Momjian2005-10-151-174/+163
|
* Allow times of 24:00:00 to match rounding behavior:Bruce Momjian2005-10-141-6/+10
| | | | | | | | | | | | | | | regression=# select '23:59:59.9'::time(0); time ---------- 24:00:00 (1 row) This is bad because: regression=# select '24:00:00'::time(0); ERROR: date/time field value out of range: "24:00:00" The last example now works.
* Fix (hopefully for the last time) problems with datetime values displayingTom Lane2005-10-091-4/+4
| | | | | | | 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.
* Andrew pointed out that the current fix didn't handle dates that wereBruce Momjian2005-07-231-8/+8
| | | | | | | | | | | 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)
* Code spacing improvement, particularly *tm spacing.Bruce Momjian2005-07-221-19/+19
|
* Update DAYS_PER_MONTH comment.Bruce Momjian2005-07-211-16/+16
| | | | Add SECS_PER_YEAR and MINS_PER_HOUR macros.
* Remove unnecessary parentheses in assignments.Bruce Momjian2005-07-211-3/+3
| | | | | Add spaces where needed. Reference time interval variables as tinterval.
* Add time/date macros for code clarity:Bruce Momjian2005-07-211-34/+34
| | | | | | | #define DAYS_PER_YEAR 365.25 #define MONTHS_PER_YEAR 12 #define DAYS_PER_MONTH 30 #define HOURS_PER_DAY 24
* Change 5e0 to 5.0, for consistency.Bruce Momjian2005-07-121-2/+2
|
* Clean up the rather historically encumbered interface to now() andTom Lane2005-06-291-1/+37
| | | | | | | | current time: provide a GetCurrentTimestamp() function that returns current time in the form of a TimestampTz, instead of separate time_t and microseconds fields. This is what all the callers really want anyway, and it eliminates low-level dependencies on AbsoluteTime, which is a deprecated datatype that will have to disappear eventually.
* Display only 9 subsecond digits instead of 10 for time values, forBruce Momjian2005-05-271-7/+4
| | | | | consistency and to prevent rounding for days < 30. Also round off all trailing zeros, rather than leaving an even number of digits.
* Back out part of patch that should be applied later.Bruce Momjian2005-05-271-4/+7
|
* Fix compile of entab to use stdarg.h. Clean up includes.Bruce Momjian2005-05-271-7/+4
| | | | Marko Kreen
* Back out:Bruce Momjian2005-05-261-3/+3
| | | | | | Display only 9 not 10 digits of precision for timestamp values when using non-integer timestamps. This prevents the display of rounding errors for common values like days < 32.
* Display only 9 not 10 digits of precision for timestamp values whenBruce Momjian2005-05-261-3/+3
| | | | | using non-integer timestamps. This prevents the display of rounding errors for common values like days < 32.
* Adjust datetime parsing to be more robust. We now pass the length of theNeil Conway2005-05-261-30/+47
| | | | | | | | | | | | | | | 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.
* Remove more extraneous parentheses in date/time functions.Bruce Momjian2005-05-241-29/+29
|
* More macro cleanups for date/time.Bruce Momjian2005-05-231-8/+8
|
* Add datetime macros for constants, for clarity:Bruce Momjian2005-05-231-7/+7
| | | | | | | | #define SECS_PER_DAY 86400 #define USECS_PER_DAY INT64CONST(86400000000) #define USECS_PER_HOUR INT64CONST(3600000000) #define USECS_PER_MINUTE INT64CONST(60000000) #define USECS_PER_SEC INT64CONST(1000000)
* Remove unnecessary parentheses in datetime/timestamp code.Bruce Momjian2005-05-231-195/+192
|
* Remove excess parens, use Abs instead of : ?.Bruce Momjian2005-05-211-8/+8
|
* Fix mis-display of negative fractional seconds in interval values forTom Lane2005-04-201-8/+15
| | | | --enable-integer-datetimes case. Per report from Oliver Siegmar.
* Attached patch gets rid of the global timezone in the following steps:Bruce Momjian2005-04-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-111-2/+2
| | | | GERMAN datestyles. Ancient bug reported by Terry Lee Tucker.
* Tag appropriate files for rc3PostgreSQL Daemon2004-12-311-2/+2
| | | | | | | | 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-011-75/+65
| | | | | | | | | | | | 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-301-3/+5
|
* Pgindent run for 8.0.Bruce Momjian2004-08-291-40/+41
|
* Update copyright to 2004.Bruce Momjian2004-08-291-2/+2
|
* Cause the format of BC timestamptz output to be 'datetime zone BC' ratherTom Lane2004-07-111-17/+26
| | | | | | | 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-031-93/+106
| | | | | | | | | | | | | | | | | | | 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-311-3/+3
| | | | is actually needed. Per Oliver Elphick.
* Integrate src/timezone library for all platforms. There is more we canTom Lane2004-05-211-28/+26
| | | | | | 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-071-6/+6
| | | | | | | | | | | | | 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-301-3/+3
| | | | | | | 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-251-1/+13
| | | | | | | | | | | | | | * 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-191-2/+2
| | | | | | | | | | | 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-211-379/+2
| | | | | | | > 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-201-2/+379
| | | | | | | | | | | | | | | | | | | | | | | | 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-171-2/+2
|
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-291-1/+1
|
* Fix datetime input parsing to accept YYYY-MONTHNAME-DD and related syntaxes,Tom Lane2003-11-161-17/+64
| | | | | | 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-251-6/+5
| | | | | terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
View Lorry Controller Status