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

[Martin Maechler]

>>>>> "BDR" == Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:

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

(thank you for getting this going;  I agree that it'd make sense to have
the basic class (& basic methods) as part of "base R".

    BDR> ISO C (aka ANSI C) has time_t, but no guarantee that it is seconds past
    BDR> 1/1/1970.  POSIX in general tightens up the definitions considerably.

Most you probably know this, .. but
since there's the "unix millenium bug" aka "C millenium bug",
POSIX or it's successor will have to extend/change the definition of time_t
to use 64bit integers (or something else) instead of (32-bit) long int as
it is now, since time will overflow some time in 2038 (?).
Our structure should make sure to accomodate more than only about 2^31
seconds since 1970-Jan-01.

chron() even now uses double which should be okay, even if we'd go down to
parts of seconds -- something we might consider.  
How are financial "tick data" recorded nowadays (and in five years from now) ??

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

    BDR> I would be very happy for someone else to do this as part of chron (say),
    BDR> *but* I do think at least the basic stuff should be in base R 1.2.x.
    BDR> (Not even in package chron bundled with R.)   That way we can use
    BDR> this for calendar and file dates.

    BDR> If we go for the R list I think we do need to record the timezone
    BDR> in the list (POSIX does not).
yes!
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._