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
- 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.
- 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
Summary
When reading calendar events, the
asktool 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 underlyingstart.dateTime/timeZone, a caller can't detect or correct the error — and askingaskto "report in my local time zone" just staples a label onto the already-wrong number.The structured tools do not have this problem.
fetch(andcall-functionforcalendarView) return the real instant: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 theaskphrasing of the same day's schedule produced standard-offset times.Requests
askand calendar guidance, recommendfetch/call-function(/me/calendarView) for exact calendar reads, and note thatasktimes are approximate and may be off by the DST delta.references/fetch-work-iq.mdalready shows an events example — a short "prefer this overaskfor precise times, and convert the UTC instant yourself" note would close the gap. Thedaily-outlook-triageskill (which drives calendar reads throughask) is the main place this bites.Prefer: outlook.timezone="..."header (or equivalent) onfetchreads so events can be returned pre-localized, matching Graph's own behavior. Todayfetchexposes no headers, so callers must convert client-side.Notes
calendarView(not/me/events) for a date window —/me/eventsreturns recurring masters at their original date rather than expanded occurrences.createEventignorestimeZone) and CopilotConversation400Error for all users whose Windows timezone is FLE Standard Time (Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius). #83 (specific-zone400). This report is about the read/query path.