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