Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Date/time on glibc2 linux

From: Oleg Broytmann <phd(at)sun(dot)med(dot)ru>
To: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Date/time on glibc2 linux
Date: 1998-12-23 15:33:14
Message-ID: Pine.SOL2.3.96.SK.981223182329.380O-100000@sun.med.ru (view raw or flat)
Thread:
Lists: pgsql-hackers
Hello!

On Mon, 14 Dec 1998, Thomas G. Lockhart wrote:
> OK, I applied the fix (confined to backend/utils/adt/nabstime.c) to both
> CVS trees. This swaps the checking of HAVE_INT_TIMEZONE and HAVE_TM_ZONE
> so that the TM_ZONE takes precedence.

   There is a bug in nabstime.c, line 337 - pgsql 6.4.1. Well, I removed 2
lines, recompile postgres with DATEDEBUG and got _surprising_ results (below).

   I ran the query SELECT datetime('1998-10-01', '11:00')
   Look, it started Ok: timezone = MSK = GMT + 3h. Ok.
   Then there is a line:
datetime2tm- time is 14:00:00
   Oops, it became 14:00 somewhere. Seems postgress added GMT offset. Well,
later:
datetime2tm- (localtime) 98.09.01 18:00:00 MSD dst=1
   How nice - postgres added GMT offset once more!

   I just want to know - where? It seems there is a line of code (I am pretty
sure it is exactly one-line bug) - postgres add gmt_off where it should
not. Where?

   Detailed log:

GetCurrentAbsoluteTime- timezone is MSK -> -10800 seconds from UTC
date_in- input string is 1998-10-01
ParseDateTime- input string is 1998-10-01
ParseDateTime- set field[0] to 1998-10-01 type 2
DecodeDateTime- field[0] is 1998-10-01 (type 2)
DecodeNumber- 1998 is 1998 fmask=00000000 tmask=00000000
DecodeNumber- match 1998 (1998) as year
DecodeNumber- 10 is 10 fmask=00000004 tmask=00000000
DecodeNumber- match 10 (10) as month
DecodeNumber- 01 is 1 fmask=00000006 tmask=00000000
DecodeNumber- (2) match 1 (01) as day
DecodeDateTime- field[0] 1998 (00000000/0000000e) value is 1
DecodeDateTime- mask 0000000e (0000000e) set y1998 m10 d01 00:00:00
ParseDateTime- input string is 11:00
ParseDateTime- set field[0] to 11:00 type 3
DecodeTimeOnly- field[0] is 11:00 (type 3)
DecodeTimeOnly- field[0] 11:00 value is -1073763168
DecodeTimeOnly- mask 00001c0e (00001c00) 11:00:00 (0.000000)
date_datetime- date is 1998.10.01
date_datetime- time is 00:00:00 0.0000000
tm2datetime- date is -39484800.000000 (-457.000000 0.000000 0)
tm2datetime- time is 0.000000 00:00:00 0.000000
datetime2tm- date is -39434400.000000 (2451088.000000 50400.000000)
datetime2tm- date is 1998.10.01
datetime2tm- time is 14:00:00
datetime2tm- time is 14:00:00 0.0000000
datetime2tm- (localtime) 98.09.01 18:00:00 MSD dst=1
datetime2tm- date is 1998.10.01
datetime2tm- time is 18:00:00 0.0000000
EncodeDateTime- timezone is MSD (MSD); offset is -14400 (-10800); daylight is 1 (0)
EncodeDateTime- day is 2451088
EncodeDateTime- date result is Thu 01 Oct 18:00:00 1998 MSD

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


In response to

Responses

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-12-23 15:38:14
Subject: Re: NULL & NOT NULL
Previous:From: Thomas G. LockhartDate: 1998-12-23 14:56:15
Subject: Re: [HACKERS] bug(?) if int8 as primary key

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group