diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2004-06-03 02:08:07 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2004-06-03 02:08:07 +0000 |
| commit | 921d749bd4c34c3349f1c254d5faa2f1cec03911 (patch) | |
| tree | c349959cb92495a8231020062fa46ac1c2b57afd /src/include/utils | |
| parent | 473ac70acae41c5f1fecbb0b57e9f5be5b26ab68 (diff) | |
| download | postgresql-921d749bd4c34c3349f1c254d5faa2f1cec03911.tar.gz | |
Adjust our timezone library to use pg_time_t (typedef'd as int64) in
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.
Diffstat (limited to 'src/include/utils')
| -rw-r--r-- | src/include/utils/datetime.h | 24 | ||||
| -rw-r--r-- | src/include/utils/nabstime.h | 6 |
2 files changed, 6 insertions, 24 deletions
diff --git a/src/include/utils/datetime.h b/src/include/utils/datetime.h index 35eec95eeb..1dd379fd21 100644 --- a/src/include/utils/datetime.h +++ b/src/include/utils/datetime.h @@ -9,7 +9,7 @@ * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/utils/datetime.h,v 1.48 2004/05/21 05:08:05 tgl Exp $ + * $PostgreSQL: pgsql/src/include/utils/datetime.h,v 1.49 2004/06/03 02:08:06 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -19,7 +19,6 @@ #include <limits.h> #include <math.h> -#include "pgtime.h" #include "utils/timestamp.h" @@ -232,10 +231,11 @@ do { \ * Include check for leap year. */ -extern int day_tab[2][13]; +extern const int day_tab[2][13]; #define isleap(y) (((y) % 4) == 0 && (((y) % 100) != 0 || ((y) % 400) == 0)) + /* Julian date support for date2j() and j2date() * * IS_VALID_JULIAN checks the minimum date exactly, but is a bit sloppy @@ -257,24 +257,6 @@ extern int day_tab[2][13]; #define UNIX_EPOCH_JDATE 2440588 /* == date2j(1970, 1, 1) */ #define POSTGRES_EPOCH_JDATE 2451545 /* == date2j(2000, 1, 1) */ -/* - * Info about limits of the Unix time_t data type. We assume that time_t - * is a signed int32 with origin 1970-01-01. Note this is only relevant - * when we use the C library's time routines for timezone processing. - */ -#define UTIME_MINYEAR (1901) -#define UTIME_MINMONTH (12) -#define UTIME_MINDAY (14) -#define UTIME_MAXYEAR (2038) -#define UTIME_MAXMONTH (01) -#define UTIME_MAXDAY (18) - -#define IS_VALID_UTIME(y,m,d) ((((y) > UTIME_MINYEAR) \ - || (((y) == UTIME_MINYEAR) && (((m) > UTIME_MINMONTH) \ - || (((m) == UTIME_MINMONTH) && ((d) >= UTIME_MINDAY))))) \ - && (((y) < UTIME_MAXYEAR) \ - || (((y) == UTIME_MAXYEAR) && (((m) < UTIME_MAXMONTH) \ - || (((m) == UTIME_MAXMONTH) && ((d) <= UTIME_MAXDAY)))))) /* * Datetime input parsing routines (ParseDateTime, DecodeDateTime, etc) diff --git a/src/include/utils/nabstime.h b/src/include/utils/nabstime.h index 704e7de583..914dd9ebd7 100644 --- a/src/include/utils/nabstime.h +++ b/src/include/utils/nabstime.h @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/utils/nabstime.h,v 1.42 2004/05/21 05:08:05 tgl Exp $ + * $PostgreSQL: pgsql/src/include/utils/nabstime.h,v 1.43 2004/06/03 02:08:06 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -17,7 +17,6 @@ #include <limits.h> #include "fmgr.h" -#include "pgtime.h" #include "utils/timestamp.h" #include "utils/datetime.h" @@ -28,9 +27,10 @@ * * ---------------------------------------------------------------- */ + /* * Although time_t generally is a long int on 64 bit systems, these two - * types must be 4 bytes, because that's what the system assumes. They + * types must be 4 bytes, because that's what pg_type.h assumes. They * should be yanked (long) before 2038 and be replaced by timestamp and * interval. */ |
