aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/timestamp.c
Commit message (Collapse)AuthorAge
...
* Re-run pgindent, fixing a problem where comment lines after a blankBruce Momjian2005-11-22
| | | | | | | | | 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.
* Make SQL arrays support null elements. This commit fixes the core arrayTom Lane2005-11-17
| | | | | | | | functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
* Add comment documenting actual failure case of usingBruce Momjian2005-10-27
| | | | | interval_justify_hours in timestamp subtraction. TODO already has text description.
* Remove justify_hours call from interval_mul and interval_div, and makeTom Lane2005-10-25
| | | | | | | some small stylistic improvements in these functions. Also fix several places where TMODULO() was being used with wrong-sized quotient argument, creating a risk of overflow --- interval2tm was actually capable of going into an infinite loop because of this.
* 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.
* timestamptz_izone should return the input, not NULL, when the inputTom Lane2005-09-09
| | | | | | is a non-finite timestamp, for consistency with related functions. In other words: +infinity rotated to a different timezone is still +infinity.
* 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.
* Factor out the common subexpression month_remainder * DAYS_PER_MONTHTom Lane2005-08-25
| | | | | | | | | in interval_mul and interval_div. This avoids an optimization bug in A Certain Company's compiler (and given their explanation, I wouldn't be surprised if other compilers blow it too). Besides the code seems more clear this way --- in the original formulation, you had to mentally recognize the common subexpression in order to understand what was going on.
* Back out pfrees for justify_hour function calls.Bruce Momjian2005-08-25
|
* Fix memory leak when using justify_hours.Bruce Momjian2005-08-25
|
* Code & docs review for server instrumentation patch. File timestampsTom Lane2005-08-12
| | | | | | should surely be timestamptz not timestamp; fix some but not all of the holes in check_and_make_absolute(); other minor cleanup. Also put in the missed catversion bump.
* Fix justify_days() for integer datestamp, clean up code.Bruce Momjian2005-07-30
|
* Fix rounding problem in interval_div by using rint(), and improveBruce Momjian2005-07-24
| | | | interval_mul function.
* Improve computations of interval_div to prevent rounding problem on AIX.Bruce Momjian2005-07-23
|
* 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)
* Fix AT TIME ZONE for timestamps without time zones:Bruce Momjian2005-07-23
| | | | | | | | | test=> select (CURRENT_DATE + '05:00'::time)::timestamp at time zone 'Canada/Pacific'; timezone ------------------------ 2005-07-22 08:00:00-04 (1 row)
* Fix AT TIME ZONE for timestamps without time zones:Bruce Momjian2005-07-22
| | | | | | | | | | test=> select ('2005-07-20 00:00:00'::timestamp without time zone) at time zone 'Europe/Paris'; timezone ------------------------ 2005-07-19 22:00:00-04 Udpate documentation.
* More removal of unneeded parentheses.Bruce Momjian2005-07-22
|
* More spacing adjustmentsBruce Momjian2005-07-22
|
* Code spacing improvement, particularly *tm spacing.Bruce Momjian2005-07-22
|
* Update DAYS_PER_MONTH comment.Bruce Momjian2005-07-21
| | | | Add SECS_PER_YEAR and MINS_PER_HOUR macros.
* Fix integer timestamp build for macro changes.Bruce Momjian2005-07-21
|
* Remove unnecessary parentheses in assignments.Bruce Momjian2005-07-21
| | | | | Add spaces where needed. Reference time interval variables as tinterval.
* Add time/date macros for code clarity:Bruce Momjian2005-07-21
| | | | | | | #define DAYS_PER_YEAR 365.25 #define MONTHS_PER_YEAR 12 #define DAYS_PER_MONTH 30 #define HOURS_PER_DAY 24
* Add 'day' field to INTERVAL so 1 day interval can be distinguished fromBruce Momjian2005-07-20
| | | | | | | | | | | | | | | | 24 hours. This is very helpful for daylight savings time: select '2005-05-03 00:00:00 EST'::timestamp with time zone + '24 hours'; ?column? ---------------------- 2005-05-04 01:00:00-04 select '2005-05-03 00:00:00 EST'::timestamp with time zone + '1 day'; ?column? ---------------------- 2005-05-04 01:00:00-04 Michael Glaesemann
* Fix interval division and multiplication, before:Bruce Momjian2005-07-20
| | | | | | | | | | | | | | | | | | | test=> select '4 months'::interval / 5; ?column? --------------- 1 mon -6 days (1 row) after: test=> select '4 months'::interval / 5; ?column? ---------- 24 days (1 row) The problem was the use of rint() to round, and then find the remainder, causing the negative values.
* Improve comments for AdjustIntervalForTypmod.Bruce Momjian2005-07-12
| | | | Blank line adjustments.
* Change 5e0 to 5.0, for consistency.Bruce Momjian2005-07-12
|
* Change typreceive function API so that receive functions get the sameTom Lane2005-07-10
| | | | | | | optional arguments as text input functions, ie, typioparam OID and atttypmod. Make all the datatypes that use typmod enforce it the same way in typreceive as they do in typinput. This fixes a problem with failure to enforce length restrictions during COPY FROM BINARY.
* Fix date_trunct for December dates that are in the next year, e.g.:Bruce Momjian2005-07-04
| | | | | | | | SELECT date_trunc('week', '2002-12-31'::date); Backpatch to 8.0.X. Per report from Nick Johnson.
* Fix build break on BSD, OSX, and other systems: add missing <sys/time.h>Neil Conway2005-06-30
| | | | include.
* Clean up the rather historically encumbered interface to now() andTom Lane2005-06-29
| | | | | | | | 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.
* This patch makes it possible to use the full set of timezones when doingBruce Momjian2005-06-15
| | | | | | | | | | | | | | | | | | "AT TIME ZONE", and not just the shorlist previously available. For example: SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London'; works fine now. It will also obey whatever DST rules were in effect at just that date, which the previous implementation did not. It also supports the AT TIME ZONE on the timetz datatype. The whole handling of DST is a bit bogus there, so I chose to make it use whatever DST rules are in effect at the time of executig the query. not sure if anybody is actuallyi *using* timetz though, it seems pretty unpredictable just because of this... Magnus Hagander
* Add pg_postmaster_start_time() function.Bruce Momjian2005-06-14
| | | | | Euler Taveira de Oliveira Matthias Schmidt
* Adjust datetime parsing to be more robust. We now pass the length of theNeil Conway2005-05-26
| | | | | | | | | | | | | | | 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-24
|
* More macro cleanups for date/time.Bruce Momjian2005-05-23
|
* Add datetime macros for constants, for clarity:Bruce Momjian2005-05-23
| | | | | | | | #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-23
|
* 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
* Fix wrong week returnded by date_trunc('week') for early dates inBruce Momjian2005-04-01
| | | | | | | | January --- would return wrong year for 2005-01-01 and 2006-01-01. per report from Robert Creager. Backpatch to 8.0.X.
* 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 ...
* Fix timestamptz_age() to do calculation in local timezone not GMT, per bug 1332.Tom Lane2004-12-01
|
* Patch of 2004-03-30 corrected date_part(timestamp) for extractingTom Lane2004-11-20
| | | | | the year from a BC date, but failed to make the same fix in date_part(timestamptz).
* timestamptz_trunc() should only recalculate the timezone when truncatingTom Lane2004-11-01
| | | | | | | | | to DAY precision or coarser; leave the timezone alone when precision is HOUR or less. This avoids surprises for inputs near a DST transition time, as per example from Matthew Gabeler-Lee. (The only reason we recalculate at all is so that outputs that are supposed to represent days will come out as local midnight, and that's not relevant for sub-day precision.)
* 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
|
* > After all that about numbering centuries and millenia correctly,Bruce Momjian2004-08-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > why does CVS tip still give me > > regression=# select extract(century from now()); > date_part > ----------- > 20 > (1 row) > [ ... looks in code ... ] > > Apparently it's because you fixed only timestamp_part, and not > timestamptz_part. I'm not too sure about what timestamp_trunc or > timestamptz_trunc should do, but they may be wrong as well. Sigh... as usual, what is not tested does not work:-( > Could we have a more complete patch? Please find a submission attached. I hope it really fixes all decade, century and millenium issues for extract and *_trunc functions on interval and other timestamp types. If someone could check that the results are reasonnable, it would be great. I indeed overlooked the fact that there were two functions. The patch fixes the code so that both variants agree. I added comments to interval extractions, because it relies on the C division to have a negative remainder: -7/10 = 0 and remains -7. As for *_trunc functions, I have chosen to put the first year of the century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't think it would make sense to put 2000 (last year of the 2nd millennium) for rounding all years of the third millenium. I also fixed the code so that all decades last 10 years and decade 199 means the 1990's. I have added some tests that are relevant to deal with tricky cases. The formula may be simplified, but all these cases must pass. Please keep them. Fabien Coelho
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-08 20:36:46 +0000