Surprising length() of POSIXlt vector (PR#14073)

-----Original Message-----
From: Benilton Carvalho [mailto:bcarvalh at jhsph.edu]
Sent: Thursday, November 19, 2009 6:59 PM
To: Steven McKinney
Cc: 'mark at celos.net'; 'r-devel at stat.math.ethz.ch'
Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

Steve,

I'm no expert on this, but my understanding is that the choice was to
stick to the definition.

The help file for length() [1] says:

"For vectors (including lists) and factors the length is the number of
elements."

The help file for POSIXlt [2] (for example) says:

"Class '"POSIXlt"' is a named list of vectors representing (...)"

and then lists the 9 elements (sec / min / hour / mday / mon / year /
wday / yday / isdst).

So, by [1] length of POSIXlt objects is 9, because it "is a named list
of vectors representing (...)".

b

On Nov 20, 2009, at 12:19 AM, Steven McKinney wrote:

I've checked the archives, and this problem crops up every
few months going back for years.

What I was not able to find was an explanation of why a
function such as
 length.POSIXlt <- function(x) { length(x$sec) }
is a Bad Idea, or what it would break.  listserv threads
seem to end without presenting an answer.  R News 2001
Vol 1/2 discusses that "lots of methods are needed..."
(page 11) but I haven't found discussion of why a length
method isn't feasible.

Can anyone clarify this, or point me at the right
archive or documentation source that discusses why
objects of class POSIXlt always need to return a
length of 9?

Thanks
Steve McKinney

-----Original Message-----
From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-
project.org] On Behalf Of Benilton Carvalho
Sent: Thursday, November 19, 2009 4:29 PM
To: mark at celos.net
Cc: r-devel at stat.math.ethz.ch
Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

Check the documentation and the archives. Not a bug. b

On Nov 19, 2009, at 8:30 PM, mark at celos.net wrote:

Arrays of POSIXlt dates always return a length of 9.  This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:

strings <- paste('2009-1-', 1:31, sep='')
dates <- strptime(strings, format="%Y-%m-%d")

print(dates)
#  [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
"2009-01-05"
#  [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
"2009-01-10"
# [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
"2009-01-15"
# [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
"2009-01-20"
# [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
"2009-01-25"
# [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
"2009-01-30"
# [31] "2009-01-31"

print(length(dates))
# [1] 9

str(dates)
# POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
"2009-01-04" ...

print(dates[20])
# [1] "2009-01-20"

print(length(dates[20]))
# [1] 9

I've since realised that POSIXct makes date vectors easier,
but could we also have something like:

length.POSIXlt <- function(x) { length(x$sec) }

in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?

Thanks,
Mark <><

------

Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status =
major = 2
minor = 10.0
year = 2009
month = 10
day = 26
svn rev = 50208
language = R
version.string = R version 2.10.0 (2009-10-26)

Locale:
C

Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base