[R-SIG-Finance] Extracting Interval-Based Data From Zoo Series (Rory Winston)

[icosa atropa]

I've had similar issues with zoo and POSIXct index uniqueness.  The
existing documentation requires very careful review.

To quote Gabor,

"
The zoo function and most functions in the zoo package have
no understanding of date time classes and only require that
such classes have ordered elements and support certain methods
as defined in ?zoo so zoo is irrelevant for understanding dates, times
and timezones.
[...]
Also please read the last line of every message to r-help [which asks
that code be self-enclosed]
"

>From ?strptime,
"
*     Specific to R is '%OSn', which for output gives the seconds to '0
*     <= n <= 6' decimal places (and if '%OS' is not followed by a
      digit, it uses the setting of 'getOption("digits.secs")', or if
*     that is unset, 'n = 3'). Further, for 'strptime' '%OS' will input
      seconds including fractional seconds.  Note that '%S' ignore
      fractional parts on output.
"

Try explicitly using %OS3 and make sure your operating system supports
this by making and examining such a POSIXct vector using duplicated()
and unique() outside of the read.zoo() call to see what's _actually_
happening.

best,
christian

> # Replace zero ticks with NA, and thus locf
> coredata(eurusd)[,"bid"][coredata(eurusd)[,"bid"]==0] = NA
> coredata(eurusd)[,"ask"][coredata(eurusd)[,"ask"]==0] = NA
> eurusd <- na.locf(eurusd)
>
> I have a couple of questions:
>
> 1. I can see that as.POSIXct() can deal with millisecond resolution, but zoo
> doesnt seem to use the millis portion of the timestamp as an index variable.
> I tried to use a function as follows:
>
> convertDate <- function(x) {
>     # 2007-11-23 14:48:43.140
>     as.POSIXct(strptime(x, "%Y-%m-%d %H:%M:%OS"))
> }
>
> and then used this as the FUN argument in read.zoo(), but it still complains
> that index values must be unique. Is it possible to use a high-resolution
> index (milliseconds or an even finer recorded granularity)?

-- 
Far better an approximate answer to the right question, which is often
vague, than the exact answer to the wrong question, which can always
be made precise -- j.w. tukey