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.