Class for time of day?

library(chron)
dt <- Sys.time()
tt <- times(format(dt, "%H:%M:%S"))
tt

tt + 1/24

What is the recommended class for time of day (independent of calendar
date)?

And what is the recommended way to get the time of day from a POSIXct
object? (Not a string representation, but a computable representation.)

I have looked in the man page for DateTimeClasses, in the Time Series
Analysis Task View and in Spector's Data Manipulation book but haven't found
these. Clearly I can create my own Time class and hack around with the
internal representation of POSIXct, e.g.

? ?days <- unclass(d)/(24*3600)
? ?days-floor(days)

and write print.Time, `-.Time`, etc. etc. but I expect there is already a
standard class or CRAN package.

? ? ? ? ? -s

? ? ? ?[[alternative HTML version deleted]]

On Wed, May 20, 2009 at 12:28 PM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:

There is a times class in the chron package.

Perfect!? Just what I was looking for.

On Wed, May 20, 2009 at 12:19 PM, jim holtman <jholtman at gmail.com> wrote:

If you want the hours from a POSIXct, here is one way of doing it...

y <- difftime(x, trunc(x, units='days'), units='hours')

Ah, trunc.POSIXt -- I missed that one, thanks.

It depends on what type of computations you want to do with it.??You can
leave it as POSIXct and carry out a lot of them.? Can you specify what you
want?

I am comparing irregular time series from different days, looking at the
differences in intraday patterns.? So I want to put them on a common 0-24h
scale and then do various kinds of plots and analyses, keeping the
conventional display form (10:30 etc.) when specific times display or
print.? It looks as though chron:::times combined with trunc.POSIXt pretty
much solves my problem, except that `times` ignores the time units:

as.POSIXct('2009-3-23 12:23')-trunc(as.POSIXct('2009-3-23 12:23'),"day")

Time difference of 12.38333 hours

times(as.POSIXct('2009-3-23 12:23')-trunc(as.POSIXct('2009-3-23
12:23'),"day"))

Time in days:??????????? <<< seems to treat difftimes as raw numbers!!
[1] 12.38333

Obviously I can work around this, but shouldn't `times` give an error when
it encounters an object of unknown class rather than unsafely using its
internal representation?? Of course, better still if `times` converted
correctly....

In general, `times` has other inconsistent and peculiar behavior:

times(2) => Time in days: 2??????? Allows specifying multi-day periods, OK
times(1.5) => Time in days: 1.5?? Allows specifying fractional multi-day
periods, OK
times(0.5) => "12:00:00"?? Inconsistent format compared to times(1.5)
times("18:00:00") + times("18:00:00")? => Time in days: 1.5, OK
times("36:00:00") => error????? Why does it allow times(1.5) and
times("18:00:00") + times("18:00:00") to specify 1.5 days, but not 36 hours?
times(-0.5) => -0.5?????????? Why doesn't it print Time in days: -0.5?
times("18:00:00")/times("1:00:00") => Time in days: 18 ?? Incorrect
dimensions; meaningless result -- should be dimensionless
times("18:00:00") * times("10:00:00") => 07:30:00???? Incorrect dimensions;
meaningless result.
sin(times("18:00:00")) => 16:21:34???? Meaningless result -- should be error

It's nice that R has a class system, but if code ignores the class....

There is an article on dates and times in R News 4/1.

Thanks for the pointer.

????????? -s

On Thu, May 21, 2009 at 8:28 PM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:

It uses hours/minutes/seconds for values < 1 day and uses days and
fractions
of a day otherwise.

Yes, my examples were documenting this idiosyncracy.

For values and operations that it has not considered it falls back to
the internal representation.

Yes, my examples were documenting this bad behavior.

Most of your examples start to make sense once you realize this.

Of course I "realize" this.? That was the point of my examples.? I
understand perfectly well what is *causing* the bad behavior.? That doesn't
make it less bad.

What is the point of a class system if functions ignore the class and
perform meaningless calculations on the internal representation?

??????????? -s

On Fri, May 22, 2009 at 10:03 AM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:

Regarding division you could contribute that to the chron package.
I've contributed a few missing items and they were incorporated.

Good to know.? Maybe I'll do that....

Giving an error when it does not understand something would be
dangerous as it could break much existing code so that would
probably not be possible at this stage.

But would it break any existing *correct* code?? I find it hard to imagine
any cases where adding 1 hour of difftime to times("12:00:00") should return
1.5 days rather than 13:00:00.

The idea of defaulting to internal representations is based on
the idea that you get many features for free since the way the
internal representations work gives the right answer in many
cases.

I must admit I am rather shocked by this approach.? Getting something "for
free" is a bad bargain if what you get is nonsense.

Its best to stick with the implicit philosophy that
underlies a package. ?If you want a different philosophy then
its really tantamount to creating a new package. ?I don't
think that one is right and the other wrong but simply
represent different viewpoints.

So you would defend the "viewpoint" that 1 hour is the same thing as 1 day?

On Fri, May 22, 2009 at 12:28 PM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:

...The way this might appear in code is if someone wanted to calculate the
number of one hour intervals in 18 hours. ?One could write:

t18 <- times("18:00:00")
t1 <- times("1:00:00")
as.numeric(t18) / as.numeric(t1)

but since we all know that it uses internal representations unless it
indicates otherwise

Um, yes, I suppose that was the attitude in the 60's and 70's, but I think
we have moved on from there.? cf.
http://en.wikipedia.org/wiki/Data_abstraction

a typical code snippet might shorten it to:

as.numeric(t18 / t1)

and all such code would break if one were to cause that to generate an
error.

(18/24 day)/(1/24 day) is the perfectly meaningful dimensionless number 18,
so this code should not break with a correct implementation of '/'.? (cf.
http://en.wikipedia.org/wiki/Dimensional_analysis).? Alas, chron gives the
nonsense result of 18 days.