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

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

• Use calendarView (not /me/events) for a date window — /me/events returns recurring masters at their original date rather than expanded occurrences.
• Related but distinct: #95 (write-side createEvent ignores timeZone) and #83 (specific-zone 400). This report is about the read/query path.

Read references/fetch-work-iq.md and the daily-outlook-triage skill to see how calendar reads are currently explained and issued. Document fetch or call-function with /me/calendarView for exact times, explain UTC and DST-safe client conversion, and note the limitation of ask; done means the guidance clearly distinguishes approximate and precise reads.