New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xout not working with na.locf #215

MortenGrum opened this Issue Nov 12, 2017 · 1 comment


None yet
2 participants

MortenGrum commented Nov 12, 2017


It seems xout is not working with na.locf()

Expected behavior

That xout defines the timestamps of the output (as with na.approx() )

Minimal, reproducible example

I have two xts time series data sets. One with my data and another with time stamps that I would like to use.

xts_with_data <- as.xts(read.zoo(text='
2016-07-01 00:00:10,   1.0
2016-07-01 00:00:14,   2.0
2016-07-01 00:00:20,   3.0
2016-07-01 00:00:29,   4.0
2016-07-01 00:00:34,   5.0
2016-07-01 00:00:39,   6.0
', sep=',', index=1, tz='', format="%Y-%m-%d %H:%M:%S"))
names(xts_with_data) <- c('x')

xts_with_timestamps <- as.xts(read.zoo(text='
2016-07-01 00:00:15,   0.0
2016-07-01 00:00:20,   0.0
2016-07-01 00:00:30,   0.0
2016-07-01 00:00:35,   0.0
2016-07-01 00:00:38,   0.0
', sep=',', index=1, tz='', format="%Y-%m-%d %H:%M:%S"))

na.locf(xts_with_data, xout = index(xts_with_timestamps))

I would expect output like this

2016-07-01 00:00:15    2
2016-07-01 00:00:20    3
2016-07-01 00:00:30    4
2016-07-01 00:00:35    5
2016-07-01 00:00:38    5

but what I get is my original xts_with_data.
(it works as expected with na.approx() )

AkselA suggested (on stackoverflow) that ... "It seems like the source of your troubles is a missing feature in xts:::na.locf.xts. It might be worth letting Joshua (the developer) know, if he doesn't already."

AkselA also pointed me to a couple of workaround:

xts_all <- merge(xts_with_data, xts_with_timestamps)[,-2]
# or
na.locf.default(xts_with_data, xout=index(xts_with_timestamps))
# or
na.locf(zoo(xts_with_data), xout=index(xts_with_timestamps))



This comment has been minimized.


joshuaulrich commented Nov 15, 2017

Thanks for the report! I agree this is a bug.

@joshuaulrich joshuaulrich added the bug label Nov 15, 2017

@joshuaulrich joshuaulrich self-assigned this Nov 15, 2017

joshuaulrich added a commit that referenced this issue Mar 14, 2018

Do not coerce non-zero-width to zero-width's type
We were converting all xts objects to a common type when merging, and
we included the types of zero-width xts objects in our check. This is
a problem because zero-width objects created via the xts constructor
are numeric by default. So calling merge.xts() on any non-numeric xts
objects and a zero-width xts object returned a numeric result.

This manifested in the na.locf() test where xout is specified, because
na.approx.zoo() is called at one point. And that method does a merge
of the original object with an zero-width zoo object created via

See #215.

@joshuaulrich joshuaulrich added this to the Release 0.10-2 milestone Mar 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment