[R] read.spss and time/date information

[Prof Brian Ripley]

On Thu, 4 Mar 2004, BXC (Bendix Carstensen) wrote:

> > On Wed, 3 Mar 2004, Peter Dalgaard wrote:
> > 
> > > Torsten Hothorn <Torsten.Hothorn at rzmail.uni-erlangen.de> writes:
> > >
> > > > Could anyone give me a a hint how I can convert 13264300800 to 
> > > > 2003/02/11 again, please?
> > >
> > > > ISOdate(1582,10,14)  + 13264300800
> > > [1] "2003-02-11 13:00:00 CET"
> > > > ISOdate(1582,10,14)  +  13142476800
> > > [1] "1999-04-03 14:00:00 CEST"
> > >
> > > [October 14, 1582 is Day 1 of the Gregorian calendar.]
> > >
> > 
> > I tried January 1th 1970 as "baseline" but I never would have 
> > dreamed of October 14, 1582.
> 
> This is the day the present Gregorian calendar was instituted, replacing
> the
> old Julian that did not have leap years. So it is actually quite
> sensible
> as it is the earliest possible date that is in unbroken sequence to
> present
> times. 
> 
> Actually I am amazed that this has not been chosen as the natural origin
> for
> any of the R-pakages...

Note the numbers are large, and you would have to ensure that you have at
least 34 bits of accuracy.  You won't have that for integer storage, and
you cannot actually guarantee you have that for doubles (although we do
come pretty close to assuming IEC60559 aka IEEE754 arithmetic).  Even if 
you do have such doubles, you need 8 bytes where other representations 
work happily with 4.  (This would be less cogent if people only wanted to 
represent dates and used days and not seconds.  But then why would users 
actually care about the internal representation?)

-- 
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