[R] Problems with addition in big POSIX dates

Prof Brian Ripley ripley at stats.ox.ac.uk
Fri Aug 22 12:13:22 CEST 2003


This is simply a bug in the code that is supposed to work around these OS
limitations: on some platforms mktime was resetting the wday during the
computations to try to work on the timezone in force: using GMT works
fine.

> unlist(unclass(as.POSIXlt(test.date+24*3600, "GMT")))
  sec   min  hour  mday   mon  year  wday  yday isdst
    0     0     0     2     0   140     1     1     0

I've put a fix in for 1.8.0.

I cannot reproduce Martin's result (on RH8.0 or Solaris or Windows, and
that seems to indicate some other problem on that platform): perhaps MM 
can test under the fixed code?

On Thu, 14 Aug 2003, Martin Maechler wrote:

> >>>>> "Whit" == Whit Armstrong <Whit.Armstrong at tudor.com>
> >>>>>     on Wed, 13 Aug 2003 15:23:58 -0400 writes:
> 
>     Whit> Have you noticed any problems with big dates (>=1/1/2040) in R?
>     Whit> Here is the bit of code that I'm having trouble with:
> 
>     >> test.date <- strptime("1/1/2040",format="%m/%d/%Y")
>     >> 
>     >> unlist(test.date)
>     Whit> sec   min  hour  mday   mon  year  wday  yday isdst 
>     Whit> 0     0     0     1     0   140     0     0     0 
>     >> 
>     >> date.plus.one <- as.POSIXct(test.date) + 24*60*60
>     >> date.plus.one.lt <- as.POSIXlt(date.plus.one)
>     >> 
>     >> unlist(date.plus.one.lt)
>     Whit> sec   min  hour  mday   mon  year  wday  yday isdst 
>     Whit> 0     0     0     2     0   140     0     1     0 
> 
>     Whit> Notice that wday (the weekday, 0=Sunday, 7=Saturday) doesn't change.
> 
>     Whit> Am I missing something?
> 
> Probably the "C library millenium bug" (not official name).
> The C library standard type for timedates, "time_t", is
> "usually" encoded using 32-bit integers, measuring seconds
> since the beginning of 1970. 
> 
> It has been well-known for years that this will lead to integer
> overflow from 19 Jan 2038 :
> 
>   > as.POSIXct(strptime("1/1/1970",format="%m/%d/%Y"))+ .Machine$integer.max
>   [1] "2038-01-19 03:14:07 CET"
> 
> I had thought that the R implementation carefully used doubles
> instead of integers everywhere, but I guess we somewhere rely on
> system-internal things even here.
> 
> For me, on Intel- Linux (RH 7.3, newer gcc) it's even worse:
> 
> > unlist(date.plus.one.lt)
>   sec   min  hour  mday   mon  year  wday  yday isdst 
>     0     0     0     2     0   140     6     0     0 
> 				       ~~~~~~~~~
> i.e. `wday' has been counted backwards, and `yday' has remained at 0.
> 
> -----
> 
> I guess we have to wait for 64-bit implementations of "time_t"
> or write our own code that works around the many C-library-bugs
> we (the R community) have encountered concerning POSIX-time
> implementations.
> Prof Brian Ripley will know more on this..
> 
> Martin Maechler <maechler at stat.math.ethz.ch>	http://stat.ethz.ch/~maechler/
> Seminar fuer Statistik, ETH-Zentrum  LEO C16	Leonhardstr. 27
> ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
> phone: x-41-1-632-3408		fax: ...-1228			<><
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> 

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595




More information about the R-help mailing list