aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/timestamp.c
Commit message (Collapse)AuthorAge
...
* 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
* Add range-checking in timestamp_recv and timestamptz_recv, perTom Lane2004-06-03
| | | | Stephen Frost. Also tighten date range check in timestamp2tm.
* 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.
* I think I've finally identified the cause of the off-by-one-secondTom Lane2004-05-31
| | | | | | | | | | issue in timestamp conversion that we hacked around for so long by ignoring the seconds field from localtime(). It's simple: you have to watch out for platform-specific roundoff error when reducing a possibly-fractional timestamp to integral time_t form. In particular we should subtract off the already-determined fractional fsec field. This should be enough to get an exact answer with int64 timestamps; with float timestamps, throw in a rint() call just to be sure.
* 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.
* Please find a small patch to fix the brain damage "century" andBruce Momjian2004-04-10
| | | | | | | | | | | | | | | | | | | | | | | | "millennium" date part implementation in postgresql, both in the code and the documentation, so that it conforms to the official definition. If you do not agree with the official definition, please send your complaint to "pope@vatican.org". I'm not responsible for them;-) With the previous version, the centuries and millenniums had a wrong number and started the wrong year. Moreover century number 0, which does not exist in reality, lasted 200 years. Also, millennium number 0 lasted 2000 years. If you want postgresql to have it's own definition of "century" and "millennium" that does not conform to the one of the society, just give them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-) IMO, if someone may use the options, it means that postgresql is used for historical data, so it make sense to have an historical definition. Also, I just want to divide the year by 100 or 1000, I can do that quite easily. BACKWARD INCOMPATIBLE CHANGE Fabien Coelho - coelho@cri.ensmp.fr
* 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.
* Add timestamp-versus-timestamptz cross-type comparison functions,Tom Lane2004-03-22
| | | | | flesh out the index operator classes to include these. In passing, fix erroneous volatility marking of ACL functions.
* Localize our dependencies on the way to create NAN or INFINITY.Tom Lane2004-03-15
| | | | Per recent proposal to pghackers.
* Per a brief conversation with Tom, I've created a patch for addingBruce Momjian2004-03-05
| | | | | | | | | support for 'week' within the date_trunc function. Within the patch I added a couple of test cases and associated target output, and changed the documentation to add 'week' appropriately. Robert Creager
* Create crosstype comparison operators for date vs. timestamp and dateTom Lane2004-02-14
| | | | | | | vs. timestamptz. This allows use of indexes for expressions like datecol >= date 'today' - interval '1 month' which were formerly not indexable without casting the righthand side down from timestamp to date.
* > > I have no idea if this in Oracle or not. But it's something IBruce Momjian2003-12-25
| | | | | | | | | | | | | | | > > needed, and other people in the past asked about it too. > > It is in Oracle, but you aren't exactly on the spot. It should be > > IYYY - 4 digits ('2003') > IYY - 3 digits ('003') > IY - 2 digits ('03') > I - 1 digit ('3') Here is an updated patch that does that. Kurt Roeckx
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-29
|
* More message editing, some suggested by Alvaro HerreraPeter Eisentraut2003-09-29
|
* Message editing: remove gratuitous variations in message wording, standardizePeter Eisentraut2003-09-25
| | | | | terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-26 09:06:39 +0000