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

[Kurt Hornik]

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

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

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._