[Rd] manipulating the Date & Time classes

[Jeffrey Ryan]

Firstly, don't double post.

On Tue, Feb 8, 2011 at 2:24 PM, Mike Williamson <this.is.mvw at gmail.com> wrote:
> Hello,
>
>    This is mostly to developers, but in case I missed something in my
> literature search, I am sending this to the broader audience.
>
>
>   - Are there any plans in the works to make "time" classes a bit more
>   friendly to the rest of the "R" world?  I am not suggesting to allow for
>   fancy functions to manipulate times, per se, or to figure out how to
>   properly "add" times or anything complicated.  Just some fixes to make it
>   easier to work with the "time" classes.  Here is a sampling of some strange
>   bugs with the time classes that, to my knowledge, don't exist with any other
>   core classes:
>      1. you cannot "unlist" a time without losing the class.  E.g., if you
>      unlist "2010-12-14 20:25:40" (POSIXct), you get "1292387141", at
> least on my
>      OS & with my time zone.  Regardless of the exact number, unlisting a time
>      class converts it to a numeric.

You didn't say what your OS is, but two things spring to mind.  Why
are you calling 'unlist' on an object that isn't a list and ... "it
works for me":

> unlist(Sys.time())
[1] "2011-02-08 14:46:24.262146 CST"

>         - upon converting to a numeric, it seems there is an underlying,
>         assumed origin of "1970-01-01 00:00:00".  However, this same
> assumption does
>         not underlie the conversion *back* to a POSIX time, e.g., through
>         as.POSIXct() function.  Therefore, whenever a time is "accidentally"
>         converted to a numeric, I have to force it back to a time through
>         as.POSIXct(), *providing my own details* as to the origin.  There
>         is no easy way to find the underlying origin.  This makes me
> nervous for any
>         persistent functions I create.  If the underlying origin ever
> changes, then
>         all this code will be inaccurate.  Maybe the origin will
> never change, but
>         regardless it makes more sense to allow for the same underlying origin
>         default for "as.POSIXct" that is used when unlisting, or
> similar activities
>         that force the time into a numeric.

If it is just numeric, it shouldn't have any attribute and since the
origin isn't global, you're sort of stuck. You can keep track of it
yourself, or just leave it as the standard unix epoch.

>         2. you cannot perform functions that otherwise seem trivial, such
>      as a "max" or "min".  I understand why, for instance, adding is
> hard.  But
>      what about max or min?  Greater than or less than are possible, as is
>      order().  I have my own simple scripts using these 2 functions
> in order to
>      create a "max" & "min" for times, but it would be nice to have something
>      vetted & official.
>

> min(Sys.time()+1:10)
[1] "2011-02-08 14:59:26.40236 CST"
> max(Sys.time()+1:10)
[1] "2011-02-08 14:59:36.762224 CST"

Again, works for me.

R.version
               _
platform       x86_64-apple-darwin10.2.0
arch           x86_64
os             darwin10.2.0
system         x86_64, darwin10.2.0
status
major          2
minor          12.0
year           2010
month          10
day            15
svn rev        53317
language       R
version.string R version 2.12.0 (2010-10-15)
>


>    If others could chime in with any strange behaviors they've seen in
> working with times, maybe we could get a critical mass of issues that are
> worthy of an overhaul.
>
>                                          Thanks & Regards,
>                                                    Mike
>
>
> "Telescopes and bathyscaphes and sonar probes of Scottish lakes,
> Tacoma Narrows bridge collapse explained with abstract phase-space maps,
> Some x-ray slides, a music score, Minard's Napoleanic war:
> The most exciting frontier is charting what's already here."
>  -- xkcd
>
> --
> Help protect Wikipedia. Donate now:
> http://wikimediafoundation.org/wiki/Support_Wikipedia/en
>
>        [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.ryan at lemnica.com

www.lemnica.com