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)

Wed,  2 Jun 2004 23:08:07 -0300 (ADT)
tgl@svr1.postgresql.org (Tom Lane)
pgsql-server: Adjust our timezone library to use pg_time_t (typedef'd
	as
> 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.

Are the zic files something that should be updated for every minor 
release, or only for every major release?

Chris


Thu, 03 Jun 2004 10:23:06 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: pgsql-server: Adjust our timezone library to use pg_time_t
	(typedef'd
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Are the zic files something that should be updated for every minor 
> release, or only for every major release?

AFAIK they don't change very often.

			regards, tom lane

Wed, 02 Jun 2004 23:40:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql-server: Adjust our timezone library to use pg_time_t
	(typedef'd
Hi Tom,

> > Are the zic files something that should be updated for every minor 
> > release, or only for every major release?
> 
> AFAIK they don't change very often.
> 
I'm not sure. In Brazil, we change it every year 'cause we have 'summer
time'. See src/timezone/data/southamerica
I think we can change it when we need it.

Regards,

-- 
Euler Taveira de Oliveira
euler (at) ufgnet.ufg.br
Desenvolvedor Web e Administrador de Sistemas
UFGNet - Universidade Federal de Goiás

Thu, 3 Jun 2004 13:09:26 -0300
Euler Taveira de Oliveira <euler@ufgnet.ufg.br>
Re: pgsql-server: Adjust our timezone library to use
Euler Taveira de Oliveira <euler@ufgnet.ufg.br> writes:
>>> Are the zic files something that should be updated for every minor 
>>> release, or only for every major release?
>> 
>> AFAIK they don't change very often.
>> 
> I'm not sure. In Brazil, we change it every year 'cause we have 'summer
> time'. See src/timezone/data/southamerica

Sure, but your politicians don't invent a new rule for the transition
dates every year, do they?  Unless the rules change there's no need for
new zic files.

[ looks at southamerica zic file ... ]  Hmm, maybe they do.  I think
most places have a more settled approach though.

			regards, tom lane

Thu, 03 Jun 2004 12:23:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql-server: Adjust our timezone library to use pg_time_t
	(typedef'd