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

[Prof Brian D Ripley]

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