aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/timestamp.c
Commit message (Collapse)AuthorAge
...
* 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.
* 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.
* Call it Linux, not GNU/Linux.Bruce Momjian2003-08-26
|
* Another pgindent run with updated typedefs.Bruce Momjian2003-08-08
|
* Fix floating-point timestamp comparisons to not go nuts if NaN isTom Lane2003-08-08
| | | | | | encountered; per bug report from Christian van der Leeden 8/7/03. Also, adjust larger/smaller routines (MAX/MIN) to share code with comparisons for timestamp, interval, timetz.
* Update copyrights to 2003.Bruce Momjian2003-08-04
|
* pgindent run.Bruce Momjian2003-08-04
|
* Error message editing in utils/adt. Again thanks to Joe Conway for doingTom Lane2003-07-27
| | | | the bulk of the heavy lifting ...
* I corecting date_trunc('quarter',...) and friends because orig versionBruce Momjian2003-07-26
| | | | | | doing '2003-07-30' -> '2003-04-01', '2003-11-30' ->'2003-07-01' B?jthe Zolt?n
* Make EXTRACT(TIMEZONE) and SET/SHOW TIMEZONE follow the SQL conventionTom Lane2003-07-17
| | | | | | for the sign of timezone offsets, ie, positive is east from UTC. These were previously out of step with other operations that accept or show timezones, such as I/O of timestamptz values.
* tm2timestamp should return -1, not elog, on overflow. (In the backendTom Lane2003-07-04
| | | | | this is merely an API inconsistency, but in ecpg it's fatal.) Also, fix misconceived overflow test in HAVE_INT64_TIMESTAMP case.
* Add binary I/O routines for a bunch more datatypes. Still a few to go,Tom Lane2003-05-12
| | | | | but that was enough tedium for one day. Along the way, move the few support routines for types xid and cid into a more logical place.
* Remove unnecessary dt2local() call.Tom Lane2003-04-07
|
* 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.
* Attached is a patch that limits the range tested by horology toBruce Momjian2003-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | what is capable using integer-datatime timestamps. It does attempt to exercise the maximum allowable timestamp range. Also is a small error check when converting a timestamp from external to internal format that prevents out of range timestamps from being entered. Files patched: Index: src/backend/utils/adt/timestamp.c Added range check to prevent out of range timestamps from being used. Index: src/test/regress/sql/horology.sql Index: src/test/regress/expected/horology-no-DST-before-1970.out Index: src/test/regress/expected/horology-solaris-1947.out Limited range of timestamps being checked to Jan 1, 4713 BC to Dec 31, 294276 In creating this patch, I have seen some definite problems with integer timestamps and how they react when used near their limits. For example, the following statement gives the correct result: SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '109203489 days' AS "Dec 31, 294276"; However, this statement which is the logical inverse of the above gives incorrect results: SELECT timestamp without time zone '12/31/294276' - timestamp without time zone 'Jan 1, 4713 BC' AS "109203489 Days"; John Cochran
* Add explicit tests for division by zero to all user-accessible integerTom Lane2003-03-11
| | | | | | | | division and modulo functions, to avoid problems on OS X (which fails to trap 0 divide at all) and Windows (which traps it in some bizarre nonstandard fashion). Standardize on 'division by zero' as the one true spelling of this error message. Add regression tests as suggested by Neil Conway.
* Change EXTRACT(EPOCH FROM timestamp) so that a timestamp without time zoneTom Lane2003-02-27
| | | | | | is assumed to be in local time, not GMT. This improves consistency with other operations, which all assume local timezone when it matters. Per bug #897.
* 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 sloppy comment.Tom Lane2003-01-22
|
* Repair inconsistent rounding behavior for timestamp, time, interval,Tom Lane2003-01-09
| | | | | | per gripe from Csaba Nagy. There is still potential for platform-specific behavior for values that are exactly halfway between integers, but at least we now get the expected answer for all other cases.
* Remove NO_MKTIME_BEFORE_1970. I had speculated that it was not neededTom Lane2002-11-12
| | | | | | anymore given the mktime() workaround now done in DetermineLocalTimeZone. This has now been confirmed by Robert Bruccoleri for Irix, and I'm going to extrapolate to AIX as well.
* Add last-ditch defense against attempts to compile datetime code withTom Lane2002-09-21
| | | | -ffast-math.
* pgindent run.Bruce Momjian2002-09-04
|
* EXTRACT(EPOCH FROM timestamp) gave wrong answers in the int64-timestampTom Lane2002-09-03
| | | | | case for timestamptz input, and differently wrong answers in the float- timestamp case for timestamp input.
* 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.
* Modify array operations to include array's element type OID in theTom Lane2002-08-26
| | | | | | | | | | array header, and to compute sizing and alignment of array elements the same way normal tuple access operations do --- viz, using the tupmacs.h macros att_addlength and att_align. This makes the world safe for arrays of cstrings or intervals, and should make it much easier to write array-type-polymorphic functions; as examples see the cleanups of array_out and contrib/array_iterator. By Joe Conway and Tom Lane.
* 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
|
* Fix lookup tables used for rounding interval data values when not usingThomas G. Lockhart2002-05-14
| | | | integer datetimes. Thanks to Tom Lane for spotting the problem.
* Support alternate storage scheme of 64-bit integer for date/time types.Thomas G. Lockhart2002-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use "--enable-integer-datetimes" in configuration to use this rather than the original float8 storage. I would recommend the integer-based storage for any platform on which it is available. We perhaps should make this the default for the production release. Change timezone(timestamptz) results to return timestamp rather than a character string. Formerly, we didn't have a way to represent timestamps with an explicit time zone other than freezing the info into a string. Now, we can reasonably omit the explicit time zone from the result and return a timestamp with values appropriate for the specified time zone. Much cleaner, and if you need the time zone in the result you can put it into a character string pretty easily anyway. Allow fractional seconds in date/time types even for dates prior to 1BC. Limit timestamp data types to 6 decimal places of precision. Just right for a micro-second storage of int8 date/time types, and reduces the number of places ad-hoc rounding was occuring for the float8-based types. Use lookup tables for precision/rounding calculations for timestamp and interval types. Formerly used pow() to calculate the desired value but with a more limited range there is no reason to not type in a lookup table. Should be *much* better performance, though formerly there were some optimizations to help minimize the number of times pow() was called. Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option "--enable-integer-datetimes" and the existing internal INT64_IS_BUSTED. Add explicit date/interval operators and functions for addition and subtraction. Formerly relied on implicit type promotion from date to timestamp with time zone. Change timezone conversion functions for the timetz type from "timetz()" to "timezone()". This is consistant with other time zone coersion functions for other types. Bump the catalog version to 200204201. Fix up regression tests to reflect changes in fractional seconds representation for date/times in BC eras. All regression tests pass on my Linux box.
* Code review for improved-hashing patch. Fix some portability issuesTom Lane2002-03-09
| | | | | (char != unsigned char, Datum != uint32); make use of new hash code in dynahash hash tables and hash joins.
* Change made to elog:Bruce Momjian2002-03-06
| | | | | | | | | | | | | | | | | | | o Change all current CVS messages of NOTICE to WARNING. We were going to do this just before 7.3 beta but it has to be done now, as you will see below. o Change current INFO messages that should be controlled by client_min_messages to NOTICE. o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc. to always go to the client. o Remove INFO from the client_min_messages options and add NOTICE. Seems we do need three non-ERROR elog levels to handle the various behaviors we need for these messages. Regression passed.
* Fix bug in extract/date_part for milliseconds/miscroseconds andTatsuo Ishii2002-03-04
| | | | | | | | | | | timestamp/timestamptz combo. Now extract/date_part returns seconds*1000 or 1000000 + fraction part as the manual stats. regression test are also fixed. See the thread in pgsql-hackers: Subject: Re: [HACKERS] timestamp_part() bug? Date: Sat, 02 Mar 2002 11:29:53 +0900
* Repair bugs in declarations of routines to add timestamptz and interval.Thomas G. Lockhart2002-01-12
| | | | | | | | | Thanks to Bruce for spotting it and Tom Lane for diagnosing it. Since horology test output is changing anyway, add some date/time input tests to horology.sql. Some of these should move to the tests for the individual data types, and we perhaps should add an entire new test for "timezone" to allow manipulating the current time zone without risking damage to the results of other tests.
* Rework the date/time parsing to tighten up some cases and to enable otherThomas G. Lockhart2001-12-29
| | | | | | | | | cases which should have worked but did not. Now supports julian day (J2452271), ISO time labels (T040506) and various combinations of spaces and run-togethers of dates, times, and time zones. All regression tests pass, and I have more tests to add after the 7.2 release (don't want to require changes to the ancillary horology result files until after then).
* Tweak interval_avg support to avoid coredump with Alpha/Tru64 compiler.Tom Lane2001-11-21
| | | | Per report from Bernd Tegge.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-09 01:43:39 +0000