Skip to content

Document fetch/calendarView for exact calendar reads — ask returns unlabeled, DST-prone meeting times #160

Description

@solvaholic

Summary

When reading calendar events, the ask tool returns meeting times as a bare, human-formatted string with no timezone label (e.g. "12 PM to 1 PM"). During daylight-saving months this string can be rendered one hour early, because it appears to apply the zone's standard UTC offset rather than the current daylight offset. Because the string is unlabeled and doesn't expose the underlying start.dateTime / timeZone, a caller can't detect or correct the error — and asking ask to "report in my local time zone" just staples a label onto the already-wrong number.

The structured tools do not have this problem. fetch (and call-function for calendarView) return the real instant:

"start": { "dateTime": "2026-07-07T13:00:00.0000000", "timeZone": "UTC" }

That's an unambiguous UTC instant, so a UTC→local conversion using a real tz database (e.g. IANA zoneinfo) is DST-correct by construction. In my testing, workiq fetch -u "/me/calendarView?startDateTime=...&endDateTime=..." returned every event as {dateTime, timeZone: "UTC"} and converted cleanly to the correct local -04:00 (EDT) offset, whereas the ask phrasing of the same day's schedule produced standard-offset times.

Requests

  1. Docs (primary): In the ask and calendar guidance, recommend fetch / call-function (/me/calendarView) for exact calendar reads, and note that ask times are approximate and may be off by the DST delta. references/fetch-work-iq.md already shows an events example — a short "prefer this over ask for precise times, and convert the UTC instant yourself" note would close the gap. The daily-outlook-triage skill (which drives calendar reads through ask) is the main place this bites.
  2. Optional (enhancement): Consider honoring a Prefer: outlook.timezone="..." header (or equivalent) on fetch reads so events can be returned pre-localized, matching Graph's own behavior. Today fetch exposes no headers, so callers must convert client-side.

Notes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions