Here are some patches which fix the recently reported date/time problems
on linux/glibc2 machines. Note that these will also fix any machine
which "tests positive" for HAVE_TM_ZONE, which might include SunOS and
xBSD machines.

The symptom can be demonstrated by the following query:

  select datetime('2000-01-01'::date);

which, if there is a problem, will return a time away from midnight.
Note that your time zone must be set to something other than GMT for
this test to be meaningful.

Thanks Oleg for being persistant!

                     - Tom
Thu, 31 Dec 1998 16:58:23 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Date/time fixes for HAVE_TM_ZONE platforms
Hello!

On Thu, 31 Dec 1998, Thomas G. Lockhart wrote:
> Here are some patches which fix the recently reported date/time problems
[skip]
> Thanks Oleg for being persistant!

   Cannot apply these patches. Which version/snapshot do I need?

Oleg.
---- 
    Oleg Broytmann  National Research Surgery Centre  http://sun.med.ru/~phd/
           Programmers don't die, they just GOSUB without RETURN.


Sun, 3 Jan 1999 16:40:10 +0300 (MSK)
Oleg Broytmann <phd@sun.med.ru>
Re: Date/time fixes for HAVE_TM_ZONE platforms
>    Cannot apply these patches. Which version/snapshot do I need?

The patches are probably for the current development tree, but both
CURRENT and REL6_4 have already had the patches applied. So just refresh
your cvs snapshot if you have that available...


What version of the tree do you have?

                         - Tom

Mon, 04 Jan 1999 07:12:29 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: Date/time fixes for HAVE_TM_ZONE platforms
Hello!

On Mon, 4 Jan 1999, Thomas G. Lockhart wrote:
> What version of the tree do you have?

   I am not postgres hacker, just average user. I am running postgres for
using it (mostly as backend for CGIs). Currently I run 6.4 and do some
experiments with 6.4.1.

> >    Cannot apply these patches. Which version/snapshot do I need?
> 
> The patches are probably for the current development tree, but both
> CURRENT and REL6_4 have already had the patches applied. So just refresh
> your cvs snapshot if you have that available...

   Does this mean 6.4.2 will have it applied?

Oleg.
---- 
    Oleg Broytmann  National Research Surgery Centre  http://sun.med.ru/~phd/
           Programmers don't die, they just GOSUB without RETURN.


Tue, 5 Jan 1999 11:49:18 +0300 (MSK)
Oleg Broytmann <phd@sun.med.ru>
Re: Date/time fixes for HAVE_TM_ZONE platforms
Hello!

On Thu, 31 Dec 1998, Thomas G. Lockhart wrote:
> Here are some patches which fix the recently reported date/time problems

Postgres 6.4.2:

template1=> select datetime('1991-10-01', '11:00');
datetime                    
----------------------------
Tue 01 Oct 11:00:00 1991 EET
(1 row)

   Now the last step - timezone. I remember there was broken 6.4.1 that had
correct timezone here...
   My timezone is, of course MSK/MSD. Global tzname really is EET, but
tm->tz_name is MSK.

Oleg.
---- 
  Oleg Broytmann     http://members.tripod.com/~phd2/     phd2@earthling.net
           Programmers don't die, they just GOSUB without RETURN.


Tue, 5 Jan 1999 19:09:29 +0300 (MSK)
Oleg Broytmann <phd@sun.med.ru>
Re: Date/time fixes for HAVE_TM_ZONE platforms
> > Here are some patches which fix the date/time problems
> Postgres 6.4.2:
> Now the last step - timezone. I remember there was broken 6.4.1 that 
> had correct timezone here...
>    My timezone is, of course MSK/MSD. Global tzname really is EET, but
> tm->tz_name is MSK.

Yeah, so is mine. You will note that any year other than 1991 behaves as
you expect, and 1991 results are consistant with the Linux timezone
database (see below):

postgres=> select datetime('1991-10-01'::date);
datetime
----------------------------
Mon Sep 30 23:00:00 1991 EET
(1 row)

postgres=> select datetime('1992-10-01'::date);
datetime
----------------------------
Thu Oct 01 00:00:00 1992 MSK
(1 row)

postgres=> select datetime('1990-10-01'::date);
datetime
----------------------------
Mon Oct 01 00:00:00 1990 MSK
(1 row)

Apparently 1991 had something different for timezone handling for Moscow
time. It isn't as dumb as it sounds; in the US in 1973-4 we ran on
daylight savings time through the winter season as an energy
conservation measure:

postgres=> select '1973-02-01'::datetime;
?column?
----------------------------
Thu Feb 01 00:00:00 1973 PST
(1 row)

postgres=> select '1974-02-01'::datetime;
?column?
----------------------------
Fri Feb 01 00:00:00 1974 PDT
(1 row)

Anyway, you can see the feature in the "zic" timezone database:

golem$ zdump -v -c 2000 Europe/Moscow
<snip>
Europe/Moscow  Sat Sep 29 23:00:00 1990 GMT = Sun Sep 30 02:00:00 1990
MSK isdst=0
Europe/Moscow  Sat Mar 30 22:59:59 1991 GMT = Sun Mar 31 01:59:59 1991
MSK isdst=0
Europe/Moscow  Sat Mar 30 23:00:00 1991 GMT = Sun Mar 31 02:00:00 1991
EET DST isdst=1
Europe/Moscow  Sat Sep 28 23:59:59 1991 GMT = Sun Sep 29 02:59:59 1991
EET DST isdst=1
Europe/Moscow  Sun Sep 29 00:00:00 1991 GMT = Sun Sep 29 02:00:00 1991
EET isdst=0
Europe/Moscow  Sat Jan 18 23:59:59 1992 GMT = Sun Jan 19 01:59:59 1992
EET isdst=0
Europe/Moscow  Sun Jan 19 00:00:00 1992 GMT = Sun Jan 19 03:00:00 1992
MSK isdst=0
Europe/Moscow  Sat Mar 28 22:59:59 1992 GMT = Sun Mar 29 01:59:59 1992
MSK isdst=0
Europe/Moscow  Sat Mar 28 23:00:00 1992 GMT = Sun Mar 29 03:00:00 1992
MSD isdst=1
<snip>

                    - Tom

Tue, 05 Jan 1999 17:16:03 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: Date/time fixes for HAVE_TM_ZONE platforms
Hello!

   I have choosed nice test case, right? :)))
   Of course, I knew this before, just completely forgot when I got good
source for zic. I haven't looked into it for a while.
   Ok, I'll recreate patch for datetime regression test and submit it
tomorrow.
   Thank you.

On Tue, 5 Jan 1999, Thomas G. Lockhart wrote:
> Yeah, so is mine. You will note that any year other than 1991 behaves as
> you expect, and 1991 results are consistant with the Linux timezone
> database (see below):
> 
> postgres=> select datetime('1991-10-01'::date);
> datetime
> ----------------------------
> Mon Sep 30 23:00:00 1991 EET
> (1 row)
> 
> postgres=> select datetime('1992-10-01'::date);
> datetime
> ----------------------------
> Thu Oct 01 00:00:00 1992 MSK
> (1 row)
> 
> postgres=> select datetime('1990-10-01'::date);
> datetime
> ----------------------------
> Mon Oct 01 00:00:00 1990 MSK
> (1 row)
> 
> Apparently 1991 had something different for timezone handling for Moscow
> time. It isn't as dumb as it sounds; in the US in 1973-4 we ran on
> daylight savings time through the winter season as an energy
> conservation measure:
> 
> postgres=> select '1973-02-01'::datetime;
> ?column?
> ----------------------------
> Thu Feb 01 00:00:00 1973 PST
> (1 row)
> 
> postgres=> select '1974-02-01'::datetime;
> ?column?
> ----------------------------
> Fri Feb 01 00:00:00 1974 PDT
> (1 row)
> 
> Anyway, you can see the feature in the "zic" timezone database:
> 
> golem$ zdump -v -c 2000 Europe/Moscow
> <snip>
> Europe/Moscow  Sat Sep 29 23:00:00 1990 GMT = Sun Sep 30 02:00:00 1990
> MSK isdst=0
> Europe/Moscow  Sat Mar 30 22:59:59 1991 GMT = Sun Mar 31 01:59:59 1991
> MSK isdst=0
> Europe/Moscow  Sat Mar 30 23:00:00 1991 GMT = Sun Mar 31 02:00:00 1991
> EET DST isdst=1
> Europe/Moscow  Sat Sep 28 23:59:59 1991 GMT = Sun Sep 29 02:59:59 1991
> EET DST isdst=1
> Europe/Moscow  Sun Sep 29 00:00:00 1991 GMT = Sun Sep 29 02:00:00 1991
> EET isdst=0
> Europe/Moscow  Sat Jan 18 23:59:59 1992 GMT = Sun Jan 19 01:59:59 1992
> EET isdst=0
> Europe/Moscow  Sun Jan 19 00:00:00 1992 GMT = Sun Jan 19 03:00:00 1992
> MSK isdst=0
> Europe/Moscow  Sat Mar 28 22:59:59 1992 GMT = Sun Mar 29 01:59:59 1992
> MSK isdst=0
> Europe/Moscow  Sat Mar 28 23:00:00 1992 GMT = Sun Mar 29 03:00:00 1992
> MSD isdst=1
> <snip>
> 
>                     - Tom
> 

Oleg.
---- 
  Oleg Broytmann     http://members.tripod.com/~phd2/     phd2@earthling.net
           Programmers don't die, they just GOSUB without RETURN.


Tue, 5 Jan 1999 20:26:35 +0300 (MSK)
Oleg Broytmann <phd@sun.med.ru>
Re: [HACKERS] Re: Date/time fixes for HAVE_TM_ZONE platforms