You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note to users: update #263 on Jun 20 introduced a bug that could lead to date/time variables in the downloaded response dataframe to be off by 1 or more hours. Times displayed would reflect UTC time wrongly interpreted in the local time zone, or some other zone if time_zone was given explicitly.
This bug did not arrive on CRAN, so only downloads made the development version between then and now would have their data affected. The issue should now be fixed.
Re-downloading may be the easiest fix. If that is not possible, you should be able to do the following to correct your response data frame (here called dat):
dat|>
mutate(
across(
c(StartDate, EndDate, RecordedDate),
~lubridate::force_tz(.x, "UTC") |>lubridate::with_tz(Sys.timezone()) # Replace Sys.timezone() with alternative if used during download
)
)
The text was updated successfully, but these errors were encountered:
I'll be honest @jmobrien that I don't have many grand plans or goals for a next release here. 🙈 I would guess not super soon, since there are not that a ton of user-facing changes since the last release yet and none of extremely urgent? That bug fix would be nice to get to folks before the end of the year, for sure, and by then there will probably be a few more updates.
That makes sense; I think I was feeling similarly. One goal I've been wondering about is whether one key goal before the next (substantial) release should be to clear out all the V2 stuff (column_map(), metadata()survey_questions()), updating where appropriate. That would help clarify the package and improve ongoing maintenance a lot, I'd think.
Note to users: update #263 on Jun 20 introduced a bug that could lead to date/time variables in the downloaded response dataframe to be off by 1 or more hours. Times displayed would reflect UTC time wrongly interpreted in the local time zone, or some other zone if
time_zone
was given explicitly.This bug did not arrive on CRAN, so only downloads made the development version between then and now would have their data affected. The issue should now be fixed.
Re-downloading may be the easiest fix. If that is not possible, you should be able to do the following to correct your response data frame (here called
dat
):The text was updated successfully, but these errors were encountered: