Thread

1. Re: Bug #630: date/time storage problem: timestamp parsed

   Andreas Schwab <schwab@suse.de> — 2002-04-11T15:17:50Z

   Thomas Lockhart <lockhart@fourpalms.org> writes:
   
   |> > > I don't think that our code checks explicitly for a "-1" return, since
   |> > > the range is checked just before the call, but it would probably be a
   |> > > good idea if it did
   |> > As I noticd yesterday, glibc's mktime() has in the current snapshot
   |> > been changed to return -1 for dates before the epoch. Our glibc guru
   |> > (Cc'ed) told me, this is according to the standards (C and POSIX)
   |> > which say, that time_t is undefined for dates prior the epoch, which
   |> > to me seems obvoius, because otherwise the error return couldn't be
   |> > distinguished from the time_t value "one second before the epoch").
   |> 
   |> ??!! I'm sorry that I don't remember the exact context here (didn't this
   |> thread start on a FreeBSD amchine?), but are you saying that glibc
   |> shipped with Linux will potentially stop supporting times and time zones
   |> before 1970?
   |> 
   |> Standard or not, there is a *long* history of all decent implementations
   |> supporting dates prior to 1970, and platforms which do not do so (AIX?)
   |> have always been a source of scorn and derision. Really.
   
   This is the bug report against glibc that prompted the change:
   
   http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738
   
   |> Ah, but this might explain why I've always seen on my Linux box a 1
   |> second offset returned from mktime() for dates before 1970. Everything
   |> is shifted to allow -1 to be a special value I'll bet...
   
   This is a joke, isn't it?
   
   |> Yikes. That is not currently acceptable (most platforms deployed in the
   |> world *do* handle dates and times before 1970), but if I'm understanding
   |> things correctly we will need to somehow reimplement the entire time and
   |> time zone support system within PostgreSQL. I'll start looking at the
   |> FreeBSD code to see what is available. *sigh*
   
   Since POSIX says years before 1970 are undefined, it seems you are right.
   
   Andreas.
   
   -- 
   Andreas Schwab, SuSE Labs, schwab@suse.de
   SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
   Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
   "And now for something completely different."
   
   

2. Re: Bug #630: date/time storage problem: timestamp parsed

   Thomas Lockhart <lockhart@fourpalms.org> — 2002-04-11T15:59:58Z

   > This is the bug report against glibc that prompted the change:
   > http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738
   > |> Ah, but this might explain why I've always seen on my Linux box a 1
   > |> second offset returned from mktime() for dates before 1970. Everything
   > |> is shifted to allow -1 to be a special value I'll bet...
   > This is a joke, isn't it?
   
   Yes and no; the behavior is in localtime(), not mktime() -- sorry for my
   faulty memory. The case I am handling is in recovering local time given
   a time_t (in UTC of course). I have independently derived a broken-down
   time structure, so have both the original structure and the results of
   localtime() available in my code. Here is the relevant comment snippet:
   
   /* XXX HACK
    * Argh! My Linux box puts in a 1 second offset for dates less than 1970
    *      but only if the seconds field was non-zero. So, don't copy the
   seconds
    *      field and instead carry forward from the original - thomas
   97/06/18
    * Note that GNU/Linux uses the standard freeware zic package as do
    *      many other platforms so this may not be GNU/Linux/ix86-specific.
    * Still shows a problem on my up to date Linux box - thomas 2001-01-17
    */
   
   Believe it or not, the workaround works :)
   
   > |> Yikes. That is not currently acceptable (most platforms deployed in the
   > |> world *do* handle dates and times before 1970), but if I'm understanding
   > |> things correctly we will need to somehow reimplement the entire time and
   > |> time zone support system within PostgreSQL. I'll start looking at the
   > |> FreeBSD code to see what is available. *sigh*
   > Since POSIX says years before 1970 are undefined, it seems you are right.
   
   Well, "undefined" does not mean "impossible" or "disallowed". Presumably
   the standard was written to accomodate AIX, which has apparently never
   supported times before 1970. Of the other 25 or so platforms PostgreSQL
   runs on, only a very few machines do not support times before 1970
   though I am sorry that I can not tell you which ones. It will be a list
   of rather odd machines; hopefully Linux will not join them.
   
   You might look to Solaris as an (imho) exemplary implementation of
   date/time support. Their time zone databases are quite detailed and
   specific for variations during years prior to 1960, including a bunch of
   weird years here in the US during the 1940's.
   
   From my PoV (which is strongly influenced by the large amount of work I
   have done with dates and times, both in PostgreSQL and in my other work
   in astronomical and satellite tracking) supporting dates and times
   before 1970 is important. I'm an old guy, relatively speaking; my
   computers should at least be able to handle times back to my birthday!!
   ;)
   
   I sympathize with the inclination to look to standards when trying to
   resolve a problem (we do this in PostgreSQL also). In fact, time zone
   handling was controversial enough for the SQL standards people that they
   gave up and defined only constant interval offsets and ignore DST and
   other features of the real-world. 
   
   But I can only imagine how many applications will be broken if this
   change actually makes it into production. I would strongly encourage you
   and your team to reconsider this change to fundamental glibc date/time
   support.
   
   Regards.
   
                           - Thomas
   
   

3. Re: Bug #630: date/time storage problem: timestamp parsed

   Andreas Schwab <schwab@suse.de> — 2002-04-11T16:19:24Z

   Thomas Lockhart <lockhart@fourpalms.org> writes:
   
   |> > This is the bug report against glibc that prompted the change:
   |> > http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738
   |> > |> Ah, but this might explain why I've always seen on my Linux box a 1
   |> > |> second offset returned from mktime() for dates before 1970. Everything
   |> > |> is shifted to allow -1 to be a special value I'll bet...
   |> > This is a joke, isn't it?
   |> 
   |> Yes and no; the behavior is in localtime(), not mktime() -- sorry for my
   |> faulty memory. The case I am handling is in recovering local time given
   |> a time_t (in UTC of course). I have independently derived a broken-down
   |> time structure, so have both the original structure and the results of
   |> localtime() available in my code. Here is the relevant comment snippet:
   
   Do you have a testcase?
   
   Andreas.
   
   -- 
   Andreas Schwab, SuSE Labs, schwab@suse.de
   SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
   Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
   "And now for something completely different."