`call_graph_url()` serializes POSIXct body fields as ambiguous, offset-less datetime strings

Open
#40 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
r
Domain
api

Research direction

Start in R/call_graph.R at call_graph_url() and reproduce the JSON output shown in the issue with a POSIXct value. Trace how request-body values are serialized, then verify that POSIXct values become UTC ISO 8601 strings ending in Z and Date values use the expected date format, including when nested in the body.

Written by the indexing model from the issue text.

Description

call_graph_url() serializes JSON request bodies with:

# R/call_graph.R, call_graph_url()
body <- jsonlite::toJSON(body[!null], auto_unbox = TRUE, digits = 22, null = "null")

This uses jsonlite's default POSIXt = "string" handling, which calls format()/as.character() on POSIXct values. That respects the object's tzone attribute but appends no UTC offset or "Z" suffix, so the resulting string is ambiguous about what instant it represents.

Microsoft Graph's OData Edm.DateTimeOffset fields expect an explicit ISO 8601 string with a Z or numeric offset (e.g. "2022-07-31T14:05:19Z"); sending a bare "2022-07-31 14:05:19" leaves Graph to guess the offset, which I think resolves against the site/tenant's regional timezone, silently shifting the stored instant away from the value the caller intended.

library(jsonlite)

x <- as.POSIXct(1659276319, origin = "1970-01-01", tz = "UTC")

# This mirrors call_graph_url()'s exact serialization call:
jsonlite::toJSON(
    list(dateTimeField = x),
    auto_unbox = TRUE,
    digits = 22,
    null = "null"
)
#> {"dateTimeField":"2022-07-31 14:05:19"}

# Confirming it's not just a formatting-style choice: jsonlite's "ISO8601"
# option has the same ambiguity, just with a "T" separator instead of a space
jsonlite::toJSON(list(dateTimeField = x), POSIXt = "ISO8601", auto_unbox = TRUE)
#> {"dateTimeField":"2022-07-31T14:05:19"}
#  still no "Z"/offset

# The only unambiguous encoding requires explicit UTC formatting:
strftime(x, "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")
#> [1] "2022-07-31T14:05:19Z"

Created on 2026-09-09 with reprex v2.1.1

Expected: A POSIXct value passed in a request body to call_graph_url() should serialize to an unambiguous ISO 8601 UTC string (...Z) matching what Graph's OData Edm.DateTimeOffset fields expect, regardless of the POSIXct object's tzone attribute or the caller's Sys.timezone().

Actual: The serialized string carries no UTC marker at all, so any Graph endpoint accepting a dateTime/DateTimeOffset field is handed an ambiguous value whenever a caller passes a native POSIXct.

Suggested fix: In call_graph_url(), before calling jsonlite::toJSON(), recursively convert any POSIXct (and Date) elements of body to explicit UTC ISO 8601 strings, e.g. strftime(x, "%Y-%m-%dT%H:%M:%SZ", tz = "UTC") for POSIXct and strftime(x, "%Y-%m-%d", tz = "UTC") for Date. Neither of jsonlite's built-in POSIXt options ("string", "ISO8601") is sufficient on their own, since neither appends a UTC offset.

Dominant language
R
Stars
38
Forks
22
Avg merge
2d 8h
Merged PRs (30d)
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.

More from Azure/AzureGraph

All issues in Azure/AzureGraph

Similar issues

More R issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.