posit-dev / posit-dev/connectapi

get_variant_schedule always reports next run as UTC (even if schedule is set-up in different time-zone)

Open
#167 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
R
Stars
54
Forks
27
Avg merge
1d 3m
Merged PRs (30d)
1

Description

Dear,

While I am aware that the get_variant_schedule is still to be considered experimental, I would like to report a potential bug to help improve it.

Problem description

Currently, if a schedule is set in, for example, GMT+2 (Brussels, CEST), the output of get_variant_schedule(variant)$schedule_data$next_run is reported as: "2022-09-13T14:05:19Z" (i.e. being "Zulu" time or UTC).

Parsing with as.POSIXct leads to the time being recognized as UTC. This is incorrect, since it is actually should read: "2022-09-13T14:05:19+02:00" to be correct (and ISO8601 compliant).
Alternatively, the time could be given in UTC as well, but then should be substracted by 2 h (in this case): "2022-09-13T12:05:19Z"

Reprex

Hard to provide a code reprex, since I mostly use the GUI to set a schedule. The following steps should be sufficient to reproduce.

  1. Deploy an Rmarkdown document that can generate scheduled output to Rstudio connect
  2. Set the schedule in a timezone other than UTC
  3. Query the published item using item <- connectapi::content_item
  4. Get the item's default variant using default_variant <- connectapi::get_variant_default(item)
  5. Get the default variant's schedule using default_schedule <- connectapi::get_variant_schedule(own_default_variant)
  6. Inspect the output of default_schedule$schedule_data$next_run

Session information

  • R 4.2.1
  • RStudio connect 2022.07.0
  • connectapi 0.1.1.1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the get_variant_schedule entry point and trace how schedule_data$next_run is parsed or formatted. Reproduce the issue by creating a schedule in a non-UTC timezone, then inspect the returned timestamp; done means the timezone offset and instant are represented correctly.

Written by the indexing model from the issue text.

Assessment

Tech stack
r
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.