Possible DST bug in the MCP beta:

I asked the assistant to create “Volunteer Call” for Sunday, November 1, 2026 at 2 p.m. My Griply account time zone is America/Toronto.

Creation succeeded, but the app displays 1 p.m. Both get_tasks and get_planning return 14:00 in America/Toronto.

As a comparison, we created “Test Task” for Saturday, October 31 at 2 p.m. using the same approach. Both the app and MCP correctly show 2 p.m.

Toronto’s clocks go back on November 1, so this suggests a DST conversion issue across the transition. We can’t tell whether it originates in MCP creation, readback, or the app’s display. The confirmed issue is that Sunday’s task displays one hour earlier than requested, while MCP readback still reports the requested time. Neither task was modified afterward.

Technical details

The optional timezone parameter was omitted from all calls to use the account setting. Griply returned timeZone: "America/Toronto" and today: "2026-10-30".

Sunday create_tasks request:

{

"tasks": [{

"name": "Volunteer Call",

"date": "2026-11-01",

"start": "14:00",

"clientRequestId": "volunteer-call-2026-11-01-1400"

}]

}

Sunday creation response (structured content):

{

"results": [{

"index": 0,

"id": "8gE5v02lVJHX0n5xxBaY",

"type": "todo",

"created": true

}]

}

Saturday create_tasks request:

{

"tasks": [{

"name": "Test Task",

"date": "2026-10-31",

"start": "14:00",

"clientRequestId": "test-task-2026-10-31-1400"

}]

}

Saturday creation response (structured content):

{

"results": [{

"index": 0,

"id": "CRWuN8mBd741pQw4HPR8",

"type": "todo",

"created": true

}]

}

Neither creation response echoed the saved date or time.

Final get_tasks request:

{

"taskIds": [

"CRWuN8mBd741pQw4HPR8",

"8gE5v02lVJHX0n5xxBaY"

]

}

Relevant fields from the final get_tasks response:

{

"timeZone": "America/Toronto",

"today": "2026-10-30",

"tasks": [

{

"id": "CRWuN8mBd741pQw4HPR8",

"name": "Test Task",

"date": "2026-10-31",

"weekday": "Saturday",

"start": "14:00"

},

{

"id": "8gE5v02lVJHX0n5xxBaY",

"name": "Volunteer Call",

"date": "2026-11-01",

"weekday": "Sunday",

"start": "14:00"

}

]

}

Additional get_planning request:

{

"from": "2026-11-01",

"to": "2026-11-01"

}

That response also returned Volunteer Call with start: "14:00" and timeZone: "America/Toronto". No underlying UTC timestamp or numeric offset was exposed in these responses.