[brookslogan]

Checklist

Please:

• Make sure this PR is against "dev", not "main" (unless this is a release
  PR).
• Request a review from one of the current main reviewers:
  brookslogan, nmdefries.
• Makes sure to bump the version number in DESCRIPTION. Always increment
  the patch version number (the third number), unless you are making a
  release PR from dev to main, in which case increment the minor version
  number (the second number).
• Describe changes made in NEWS.md, making sure breaking changes
  (backwards-incompatible changes to the documented interface) are noted.
  Collect the changes under the next release number (e.g. if you are on
  1.7.2, then write your changes under the 1.8 heading).
• Styling and documentation checks. Make a PR comment with:
  • /style to check the style and fix any issues.
  • /document to check the package documentation and fix any issues.
  • /preview-docs to preview the docs.
  • See Actions GitHub tab to track progress of these commands.
• See DEVELOPMENT.md for more information on the development
  process.

Change explanations for reviewer

Follow-up on #753 (comment).

It looks like fluview in API has report times that have already been converted to dates, but this works to resolve report date non-uniqueness complaints from naive workarounds for VA data. Claims version history is large and takes a while to download; I'm aborting my test there.

Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch

[JavierMtzRdz]

It looks almost ready. I caught a couple of bugs and added a couple of suggestions.

[brookslogan]

Thanks for the bug catching! Could I get your thoughts on one design point as well? When determining the the date calculation time zone, should we consider the display timezone of the POSIXct object?

I currently am using the display timezone of the POSIXct object fed in, if there is one. This means that

• if a package / user has set the POSIXct to display in a particular time zone like America/New_York, we use America/New_York to calculate date membership --- this is good; presumably they set it to reflect the time in a data set-relevant time zone
• if a package / user uses as.POSIXct(<character>, tz = "UTC") to perform datetime parsing knowing that has been standardized to UTC, it also sets the display tz to UTC, and date calculations assume we're working with UTC dates --- this is bad, and I'm guessing that we may run into this with current epidatr
• noon UTC, displayed in most/all timezones, seems like it should work either way
• midnight UTC doesn't actually require the hack now, but we're still using it anyway to determine whether to convert silently or not

Any feelings on whether we should continue to consider it vs. just assume based on the session tz?

[brookslogan]

• todo: stop paying attention to the display tzone of POSIXcts when converting them to dates in epiprocess (and just assume we calculate Dates based on the R session's tz)

This is because parsing datetimes provided in UTC, such as from the Epidata API, will often set the display tzone as UTC as well. It's that way in the current version of epidatr, and also if we were to directly use as.POSIXct(<character>, tz = "UTC") without then resetting the display tzone. So in these cases, we'd currently be aligning to UTC dates rather than around-ET dates expected to be more relevant for most/all of our users.

Looking further: our users / CRAN may run things in Actions/AWS/etc. where the system time zone may be set to UTC, which is also not desirable, so this may not be the permanent solution. We might decide to either (a) have epidatr start setting the display tz to ET after it's done parsing, or (b) try to detect when we're running in Actions/AWS/etc. and try to give a better heads up than just the current message that they'd get.