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.
- 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.
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.
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]]
try xts package and functions: reclass period.max period.min best, daniel 2011/2/8 Mike Williamson <this.is.mvw@gmail.com>> 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. > - 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. > 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. > > 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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
Phil,
Thanks! I am not sure why min & max sometimes work & other times
don't
work. In fact, running the script as you had it did work for me. For
arrays that I had, it wasn't working and still isn't. For the moment, I
won't worry about it. It seems maybe it is a hidden bug somewhere (or I am
making an error), instead of just a simple feature to add.
Regarding switching back to POSIXct, I wasn't aware of that method to
switch back. That will save a big headache, and I'm glad I asked!!
As long as you have so many great ideas, do you know how to handle times
/ dates when using "apply"? When I use "apply", it forces
the times into
characters. E.g.:
tmp:
Col A Col B
1 2010-12-14 00:47:25 2010-12-14 20:25:40
2 2010-12-14 13:03:04 2010-12-14 20:25:45
3 2010-12-14 13:13:06 2010-12-14 20:25:41
4 2010-12-11 16:33:59 2010-12-14 20:25:41
5 2010-12-14 07:32:50 2010-12-14 20:25:41
6 2010-12-14 07:36:21 2010-12-14 20:25:45
7 2010-10-11 09:31:37 2010-12-01 14:21:42
8 2010-09-25 19:09:34 2010-09-25 21:10:50
9 2010-12-14 17:53:25 2010-12-14 20:33:49
10 2010-09-30 16:43:40 2010-12-01 15:36:07
If I perform:
- sapply(tmp, class) or lapply(tmp, class)
I get:
[1,] "POSIXt" "POSIXt"
[2,] "POSIXct" "POSIXct"
But if I perform:
- apply(tmp, 1, class)
I get:
[1] "character" "character" "character"
"character" "character" "character"
[7] "character" "character" "character"
"character"
So I cannot perform any operations on times by row, unless I touch the
dreaded "for loop". Or unless there is a secret I do not know...
Thanks!
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
On Tue, Feb 8, 2011 at 12:31 PM, Phil Spector
<spector@stat.berkeley.edu>wrote:
> Mike -
> In what sense do min and max not work?
>
> tm = as.POSIXct(c("2010-12-14 20:25:40","2010-12-10
08:15:20","2010-10-05
>> 05:12:10"))
>> min(tm)
>>
> [1] "2010-10-05 05:12:10 PDT"
>
>> max(tm)
>>
> [1] "2010-12-14 20:25:40 PST"
>
> When a POSIX time becomes numeric, try something like this:
>
> untm = as.numeric(tm)
>> untm
>>
> [1] 1292387140 1291997720 1286280730
>
>> class(untm) = 'POSIXct'
>> untm
>>
> [1] "2010-12-14 20:25:40 PST" "2010-12-10 08:15:20 PST"
> [3] "2010-10-05 05:12:10 PDT"
>
> That is, just force the class back to POSIXct, don't use as.POSIXct.
>
> Hope this helps.
> - Phil Spector
> Statistical Computing Facility
> Department of Statistics
> UC Berkeley
> spector@stat.berkeley.edu
>
>
>
> On Tue, 8 Feb 2011, Mike Williamson 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.
>> - 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.
>> 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.
>>
>> 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-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>>
[[alternative HTML version deleted]]
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
Mike, On Feb 8, 2011, at 3:24 PM, Mike Williamson 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.Same answer as Jeff said - it works for me. When posting claims like this it's good to provide some evidence like a reproducible example with details such as the version of R you used, OS etc.> - upon converting to a numeric, it seems there is an underlying, > assumed origin of "1970-01-01 00:00:00".You may want to read up on times a bit - POSIX time (aka unix time) *is* defined as number of seconds elapsed since midnight UTC 1970/1/1. That is also the internal representation of POSIXct (see ?POSIXct) that you get when unclassing it (not unlisting).> However, this same > assumption does > not underlie the conversion *back* to a POSIX time, e.g., through > as.POSIXct() function.And it would be fatal if it did. When you have a number there is no way of knowing what the origin is, that's why it has to be specified. There are many different numeric times with various origins (e.g. Apple used to have its own one before OS X, Excel uses 1900 etc. - see Epoch).> 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.In general, there is no way. *If* your numbers come from unclassing POSIXct then you can simply set the class back - which avoid other hassles such as the fact that you have no idea about the target time zone of the original number otherwise.> This makes me > nervous for any > persistent functions I create. If the underlying origin ever > changes, then > all this code will be inaccurate.POSIX time is POSIX time (aka unix time) - that's where the name comes from! If that definition changes, we'll see more issues than your code ;).> 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. > 2. you cannot perform functions that otherwise seem trivial, such > as a "max" or "min".Again, I don't believe you:> x = Sys.time() + 1:10 > min(x)[1] "2011-02-08 17:17:47 EST"> max(x)[1] "2011-02-08 17:17:56 EST"> max(x) - min(x)Time difference of 9 secs> 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. > > 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. >Please do provide some real evidence, like reproducible examples. So far none of your claims was verifiable. Cheers, Simon> 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 > >
Apparently Analagous Threads
- manipulating the Date & Time classes
- anyone know why package "RandomForest" na.roughfix is so slow??
- How to get 'R' to talk BACK to other languages / scripts??
- how to convert "sloppy data" into a time series?
- question regarding "varImpPlot" results vs. model$importance data on package "RandomForest"