pgsql-server: Adjust our timezone library to use pg_time_t (typedef'd as

From: tgl(at)svr1(dot)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql-server: Adjust our timezone library to use pg_time_t (typedef'd as
Date: 2004-06-03 02:08:07
Message-ID: 20040603020807.B0E1CD1B238@svr1.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Log Message:
-----------
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.

Modified Files:
--------------
pgsql-server/src/backend/access/transam:
xact.c (r1.167 -> r1.168)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/access/transam/xact.c.diff?r1=1.167&r2=1.168)
xlog.c (r1.145 -> r1.146)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/access/transam/xlog.c.diff?r1=1.145&r2=1.146)
pgsql-server/src/backend/bootstrap:
bootparse.y (r1.68 -> r1.69)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/bootstrap/bootparse.y.diff?r1=1.68&r2=1.69)
bootscanner.l (r1.34 -> r1.35)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/bootstrap/bootscanner.l.diff?r1=1.34&r2=1.35)
bootstrap.c (r1.182 -> r1.183)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/bootstrap/bootstrap.c.diff?r1=1.182&r2=1.183)
pgsql-server/src/backend/optimizer/geqo:
geqo_main.c (r1.44 -> r1.45)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/optimizer/geqo/geqo_main.c.diff?r1=1.44&r2=1.45)
pgsql-server/src/backend/postmaster:
bgwriter.c (r1.2 -> r1.3)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/postmaster/bgwriter.c.diff?r1=1.2&r2=1.3)
pgstat.c (r1.73 -> r1.74)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/postmaster/pgstat.c.diff?r1=1.73&r2=1.74)
postmaster.c (r1.401 -> r1.402)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/postmaster/postmaster.c.diff?r1=1.401&r2=1.402)
pgsql-server/src/backend/storage/buffer:
freelist.c (r1.43 -> r1.44)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/storage/buffer/freelist.c.diff?r1=1.43&r2=1.44)
pgsql-server/src/backend/tcop:
postgres.c (r1.417 -> r1.418)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/tcop/postgres.c.diff?r1=1.417&r2=1.418)
pgsql-server/src/backend/utils/adt:
date.c (r1.98 -> r1.99)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/date.c.diff?r1=1.98&r2=1.99)
datetime.c (r1.129 -> r1.130)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/datetime.c.diff?r1=1.129&r2=1.130)
nabstime.c (r1.122 -> r1.123)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/nabstime.c.diff?r1=1.122&r2=1.123)
timestamp.c (r1.107 -> r1.108)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/timestamp.c.diff?r1=1.107&r2=1.108)
pgsql-server/src/backend/utils/error:
elog.c (r1.139 -> r1.140)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/error/elog.c.diff?r1=1.139&r2=1.140)
pgsql-server/src/include/catalog:
pg_control.h (r1.14 -> r1.15)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/catalog/pg_control.h.diff?r1=1.14&r2=1.15)
pgsql-server/src/include/commands:
vacuum.h (r1.53 -> r1.54)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/commands/vacuum.h.diff?r1=1.53&r2=1.54)
pgsql-server/src/include:
pgtime.h (r1.1 -> r1.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/pgtime.h.diff?r1=1.1&r2=1.2)
pgsql-server/src/include/utils:
datetime.h (r1.48 -> r1.49)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/utils/datetime.h.diff?r1=1.48&r2=1.49)
nabstime.h (r1.42 -> r1.43)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/utils/nabstime.h.diff?r1=1.42&r2=1.43)
pgsql-server/src/test/regress/expected:
horology.out (r1.49 -> r1.50)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/horology.out.diff?r1=1.49&r2=1.50)
timestamp.out (r1.26 -> r1.27)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/timestamp.out.diff?r1=1.26&r2=1.27)
timestamptz.out (r1.15 -> r1.16)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/timestamptz.out.diff?r1=1.15&r2=1.16)
pgsql-server/src/timezone:
localtime.c (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/timezone/localtime.c.diff?r1=1.6&r2=1.7)
pgtz.c (r1.16 -> r1.17)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/timezone/pgtz.c.diff?r1=1.16&r2=1.17)
strftime.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/timezone/strftime.c.diff?r1=1.3&r2=1.4)
zic.c (r1.7 -> r1.8)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/timezone/zic.c.diff?r1=1.7&r2=1.8)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-06-03 02:23:06 Re: pgsql-server: Adjust our timezone library to use pg_time_t (typedef'd
Previous Message Bruce Momjian 2004-06-03 00:25:47 pgsql-server: Win32 regression fixes: .

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-06-03 02:10:13 Re: Default Locale in initdb
Previous Message pgsql 2004-06-03 01:53:46 Re: Default Locale in initdb