[Rd] RFC: System and time support functions in R

[Prof Brian Ripley]

> From: Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at>
> Date: Thu, 20 Jul 2000 13:17:35 +0200 (CEST)
> 
> >>>>> Prof Brian D Ripley writes:
> 
> > I've been looking over system utility functions that we might want to
> > add to R.  A few come out of specific needs, others from looking at
> > other systems and what people are using system() for.  I've taken
> > account of Paul Gilbert's comments posted here a while ago (and I
> > think covered all except the use of mailers).
> 
> > ...
> 
> > The other main area that needs something more is date/times.  For the
> > moment file.info returns times as days/fractional days since 1 Jan
> > 1970, which chron() can interpret.  But that is not *quite* correct,
> > as not all days are the same length due to the (rare) use of
> > leap-seconds.  And chron does not know about timezones.
> 
> > My suggestion here is to implement a time class called POSIXtime which is
> > just POSIX's time_t. (Number of seconds since 1 Jan 1970.) And another time
> > class POSIXtm which is an R list giving a struct tm (secs, mins, hours, day
> > of month, month, year, day of week, day of year).  (I think it also needs
> > to record the timezone used.)  Then we can have R functions as vectorized
> > wrappers for the POSIX functions (not necesarily with these names)
> 
> > time (say Sys.date):    date() as a POSIXtime variable.
> > localtime / gmtime:     convert POSIXtime to POSIXtm (local TZ/UTC)
> > mktime:                 convert POSIXtm to POSIXtime
> > strftime:               convert POSIXtm to character string, flexibly.
> > difftime:		difference between times in secs.
> > 			(The wrappers for the last two could handle
> > 			POSIXtime and POSIXtm objects.)
> 
> > (Perhaps if these do not exist on a platform (unlikely) we can have
> > less accurate alternatives in our code.  They exist on Windows.)
> 
> > Possibly we might want to allow
> 
> > tzset:		        set a time zone, for the above functions
> 
> > or perhaps better just have tz as an argument to the conversion functions.
> 
> > Is this is a sensible design strategy?  I am reluctant to add another
> > set of date functions after packages date and chron, but cannot see
> > how to easily leverage those to do what I need, and in any case POSIX
> > has thought this through.
> 
> David James and I are currently discussing re-implementing chron, and
> among the issues is interfacing ANSI C time & date functions as you
> suggested above.  We should also provide strptime() which is not ANSI
> but simple to implement without locale support, and maybe possible to
> take from glibc otherwise (assuming it is not in the system's libs).
> 
> (Btw, why POSIX?  K&R gave me the feeling that the above is all ANSI.)

ISO C (aka ANSI C) has time_t, but no guarantee that it is seconds past
1/1/1970.  POSIX in general tightens up the definitions considerably.

> I will cc David on this.  The R list (corresponding to struct tm) could
> as well be the basic representation of a chron object ...

I would be very happy for someone else to do this as part of chron (say),
*but* I do think at least the basic stuff should be in base R 1.2.x.
(Not even in package chron bundled with R.)   That way we can use
this for calendar and file dates.

If we go for the R list I think we do need to record the timezone in the
list (POSIX does not).

Brian

-- 
Brian D. Ripley,                  ripley@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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._