forecast.ARIMA fc_start being ill defined as NA

[AdamSpannbauer]

Monthly series with yearmonth indexed tsibble. Loading all libraries through fpp3.

The error goes away if I filter for the series to end in not May. It seems that adding 1 to a yearmonth in May leads to NA. The issue might be deeper and related to the yearmonth function itself. To recreate the issue I have to use: yearmonth("1995 Jun") + 1 since running yearmonth("1995 May") outputs 1995 Apr and running yearmonth("1995 Jun") outputs 1995 May. UPDATE: idk anymore, it seems different random yearmonths +1 can lead to NA

Reprex:

# forecast.ARIMA error reprex
library(fpp3)

data_url <- "https://docs.google.com/spreadsheets/d/1s7LfGmAv7EvpqEMe2RHcSPPKSNnBj8HmnvaDDd3A6Yw/export?format=csv"
hotels <- read.csv(data_url) %>%
  mutate(month = yearmonth(month)) %>%
  tsibble(index = month)

# No error if this filter performed:
# hotels <- hotels %>% 
#   filter_index(. ~ "1994 Dec")

hotels %>%
  model(ARIMA(revenue)) %>%
  forecast(h = 12)

hotels %>%
  model(ARIMA(revenue)) %>%
  forecast(h = 12)

Error message

Error in `mutate()`:
! Problem while computing `ARIMA(revenue) =
  (function (object, ...) ...`.
   Caused by error in `if (unclass(new_data)[[index_var(new_data)]][1] != fc_start) ...`:
     ! missing value where TRUE/FALSE needed
   Run `rlang::last_error()` to see where the error occurred.

Lines in forecast.ARIMA that lead to the error:

• This addition leads to fc_start being defined as NA: https://github.com/tidyverts/fable/blob/master/R/arima.R#L794
• Error then arises in this line due to NA comparison with fc_start here: https://github.com/tidyverts/fable/blob/master/R/arima.R#L804

Relevant package and R versions

R.version$version.string
# [1] "R version 4.2.2 (2022-10-31)"
packageVersion("fable")
# [1] ‘0.3.2’
packageVersion("fpp3")
# [1] ‘0.4.0’

[esydeaka]

I encountered the same error message using the same R version and fable version referenced above. I ended up reverting to an earlier version (v 0.3.1) to avoid the error. Not sure if it's relevant, but I am also building time series models using monthly data observations indexed using yearmonth outputs. Is anyone looking into this issue?

[AdamSpannbauer]

This issue seems like it might be related to tidyverts/tsibble#290 (comment)

(I've linked to a comment with the potential root of the issue and a potential bandaid workaround until the issue is addressed by devs)

[AdamSpannbauer]

I believe this issue is caused by an issue in the timechange package that lubridate relies on, and will be solved if this PR (vspinu/timechange#24) is merged. It is an issue related to timezones being inconsistently assumed to be UTC.

[mitchelloharawild]

Thanks for investigating this, hopefully this is resolved by upstream issues 🤞
Please advise if this continues to be an issue.