Work IQ Calendar MCP createEvent ignores timeZone parameter — defaults to Pacific Standard Time

[erik8989]

Bug: Work IQ Calendar MCP createEvent ignores timeZone parameter — defaults to Pacific Standard Time

Summary

The mcp_CalendarTools_graph_createEvent tool ignores the timeZone field in start and end parameters. All events are stored with originalStartTimeZone: "Pacific Standard Time" regardless of the timezone provided. This causes events to appear at the wrong time in the user's calendar.

Environment

• Platform: Microsoft Copilot Studio (Playground)
• Connector: Work IQ Calendar (mcp_CalendarTools), Preview
• Models tested: gpt-4o, gpt-5.4-mini, grok-4-fast-reasoning
• User mailbox timezone: W. Europe Standard Time (UTC+1 / UTC+2 CEST)
• User region: Germany (Munich)
• Date of testing: 2026-04-01

Expected behavior

When createEvent is called with timeZone: "W. Europe Standard Time" and dateTime: "2026-04-07T09:00:00", the event should be created at 09:00 W. Europe Standard Time (07:00 UTC during CEST).

The originalStartTimeZone in the response should reflect the timezone provided in the request.

Actual behavior

The connector ignores the timeZone field and interprets the dateTime value as Pacific Standard Time, causing a +9 hour offset for users in the W. Europe Standard Time zone during CEST.

The response always returns "originalStartTimeZone": "Pacific Standard Time" regardless of the timezone submitted.

Reproduction steps

Test 1: Flat parameters with IANA timezone name

Request:

{
  "operation": "CreateEvent",
  "arguments": {
    "subject": "TEST",
    "attendeeEmails": [],
    "startDateTime": "2026-04-07T09:00:00",
    "endDateTime": "2026-04-07T09:30:00",
    "timeZone": "Europe/Berlin",
    "isOnlineMeeting": false
  }
}

Result:

"originalStartTimeZone": "Pacific Standard Time"
"start": { "dateTime": "2026-04-07T09:00:00.0000000", "timeZone": "Pacific Standard Time" }

• Calendar grid shows: 18:00 (wrong, +9h offset)
• Event details show: 09:00 Pacific (wrong timezone)

Test 2: Flat parameters with Windows timezone name

Request:

{
  "operation": "CreateEvent",
  "arguments": {
    "subject": "TEST",
    "attendeeEmails": [],
    "startDateTime": "2026-04-07T09:00:00",
    "endDateTime": "2026-04-07T09:30:00",
    "timeZone": "W. Europe Standard Time",
    "isOnlineMeeting": false
  }
}

Result:

"originalStartTimeZone": "Pacific Standard Time"
"start": { "dateTime": "2026-04-07T09:00:00.0000000", "timeZone": "Pacific Standard Time" }

• Calendar grid shows: 18:00 (wrong, +9h offset)
• Event details show: 09:00 Pacific (wrong timezone)

Test 3: Flat parameters with UTC

Request:

{
  "operation": "CreateEvent",
  "arguments": {
    "subject": "TEST",
    "attendeeEmails": [],
    "startDateTime": "2026-04-07T09:00:00",
    "endDateTime": "2026-04-07T09:30:00",
    "timeZone": "UTC",
    "isOnlineMeeting": false
  }
}

Result:

"originalStartTimeZone": "Pacific Standard Time"

• Same behavior — timeZone field completely ignored.

Test 4: Inline UTC offset in dateTime string

Request:

{
  "operation": "CreateEvent",
  "arguments": {
    "subject": "OFFSET-TEST",
    "attendeeEmails": [],
    "startDateTime": "2026-04-07T09:00:00+02:00",
    "endDateTime": "2026-04-07T09:30:00+02:00",
    "timeZone": "W. Europe Standard Time",
    "isOnlineMeeting": false
  }
}

Result:

"originalStartTimeZone": "UTC"
"start": { "dateTime": "2026-04-07T07:00:00.0000000", "timeZone": "UTC" }

• Calendar grid shows: 09:00 (correct!)
• Event details show: 07:00 UTC (wrong — should show 09:00 local)
• The +02:00 offset is correctly converted to UTC, but originalStartTimeZone is set to "UTC" instead of "W. Europe Standard Time"

Test 5: Nested start/end objects (matching API documentation)

Request:

{
  "operation": "CreateEvent",
  "arguments": {
    "subject": "NESTED-TEST",
    "start": { "dateTime": "2026-04-07T09:00:00", "timeZone": "W. Europe Standard Time" },
    "end": { "dateTime": "2026-04-07T09:30:00", "timeZone": "W. Europe Standard Time" },
    "attendeeEmails": [],
    "isOnlineMeeting": false
  }
}

Result:

• Event details show: 09:00 – 09:30 (correct!)
• Calendar grid shows: 18:00 (wrong, +9h offset)
• Nested objects correctly set the timezone metadata but the time calculation is still wrong

Test 6: Nested objects + inline offset (combination)

Request:

{
  "operation": "CreateEvent",
  "arguments": {
    "subject": "KOMBI-TEST",
    "start": { "dateTime": "2026-04-07T09:00:00+02:00", "timeZone": "W. Europe Standard Time" },
    "end": { "dateTime": "2026-04-07T09:30:00+02:00", "timeZone": "W. Europe Standard Time" },
    "attendeeEmails": [],
    "isOnlineMeeting": false
  }
}

Result:

• Calendar grid shows: 09:00 (correct!)
• Event details show: 07:00 (wrong — shows UTC)
• Same behavior as Test 4 — inline offset fixes the time but metadata still shows UTC

Summary of results

Method	Grid	Details	originalStartTimeZone
Flat + Europe/Berlin	❌ +9h	❌ Pacific	Pacific Standard Time
Flat + W. Europe Standard Time	❌ +9h	❌ Pacific	Pacific Standard Time
Flat + UTC	❌ +9h	❌ Pacific	Pacific Standard Time
+02:00 in dateTime string	✅ correct	❌ shows UTC	UTC
Nested {dateTime, timeZone}	❌ +9h	✅ correct	(correct)
Nested + +02:00	✅ correct	❌ shows UTC	UTC

No combination produces correct results for both calendar grid and event details.

Root cause analysis

The connector appears to have two separate code paths:

1. Time calculation (when the event actually occurs): Uses the dateTime value literally and defaults to Pacific Standard Time when parsing. Only inline UTC offsets (+02:00) in the dateTime string override this.

2. Timezone metadata (originalStartTimeZone): Only populated correctly when using nested start: { dateTime, timeZone } objects. Flat timeZone parameters and inline offsets do not propagate to this field.

Impact

• Events are created at the wrong time for all non-Pacific-timezone users
• Free/busy checks based on created events are unreliable
• Meeting invitations contain incorrect times
• Users cannot trust the displayed time in event details
• This effectively makes the createEvent tool unusable for production outside US Pacific timezone

Documentation contradiction

The Work IQ Calendar reference states:

• "All timestamps use UTC/ISO 8601 format with timezone"
• "Time zones should be consistent across start and end times"
• start parameter is documented as "Start timestamp with dateTime and timeZone"

The connector does not honor these documented requirements.

Workaround

No complete workaround exists. The closest partial workaround is using inline UTC offsets in the dateTime string (+02:00), which creates the event at the correct time but displays UTC in the event detail view.

Correlation IDs for traces

• c8ab12d6-ab2e-49e5-817d-16b9e5c054b4 (flat + W. Europe Standard Time)
• a3e05a9b-cbbd-4b1b-8990-0cf2f9c2fa07 (flat + W. Europe Standard Time, second test)
• 84dcf6f2-a3e1-4413-8af4-7c305701a725 (flat + W. Europe Standard Time, gpt-5.4-mini)
• 41b891f4-2b40-4302-84ec-868e28c41273 (inline +02:00 offset)

User mailbox settings (confirmed correct)

{
  "timeZone": "W. Europe Standard Time",
  "workingHours": {
    "daysOfWeek": [1, 2, 3, 4, 5],
    "startTime": { "hour": 8, "minute": 0 },
    "endTime": { "hour": 17, "minute": 0 },
    "timeZone": { "name": "W. Europe Standard Time" }
  }
}

[lewiswigmore]

Hit the same thing today, I'm in the UK (GMT Standard Time, currently BST/UTC+1) using Copilot CLI with Agency's calendar MCP proxy.

Tried passing "GMT Standard Time", "UTC", both ignored and always comes back as Pacific Standard Time. Only thing that actually works is baking the offset into the dateTime string itself (e.g. 2026-04-02T12:00:00+01:00), which matches your Test 4. Grid time is correct but details show UTC.

I looked into Agency's proxy code (mcp_interceptor.rs, mcp_proxy.rs) to check if it was stripping the timezone but it's not. The proxy is a pure passthrough, so the timeZone value is definitely reaching agent365 intact. Bug is server-side in mcp_CalendarTools.

Until this is fixed server-side, it might be worth contributing a workaround skill to microsoft/work-iq that auto-converts local times to inline UTC offsets before calling the calendar MCP or at least as a documented interim solution for non-PST users.