[Rd] RFC: System and time support functions in R
Prof Brian D Ripley
ripley@stats.ox.ac.uk
Thu, 20 Jul 2000 08:33:01 +0100 (BST)
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).
We currently have
date
*.socket
file.create
file.exists
file.remove
file.append
dir.create
basename
dirname
list.file/dir
unlink -- it is none too clear what this should do for dirs.
file.show
getenv
S-PLUS 5.x has
access
files.in.dir -- we have list.files.
is.dir
mkdir -- we have dir.create
rmdir -- recursive or not (unlink only removes empty directories)
I have added today for R-devel (Unix and Wundows)
file.access() -- an access() work-alike.
file.info() -- subsumes is.dir(), and give the information from
stat(2) calls.
file.copy -- via file.create and file.append.
Sys.info() -- give the information from uname(2) (including machine
name) and getlogin(2) (the login name).
Things which I think we still may need:
putenv() -- or is `setenv' a better name? (putenv is the POSIX name).
sleep() -- called Sys.sleep()?, and with sub-second accuracy.
Tricky to do with event loops running, but looks possible.
Package xgobi under Unix has system("sleep 3"), which is
not a good idea in an event-driven system. I have this
running on Windows for xgobi there.
unlink() -- I suggest we add a recursive argument, defaulting to
FALSE? (It is currently TRUE on most platforms.)
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.
--
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._