Three submission deadlines this quarter. Right now they're on a sticky note. You said on Day 9 that was a terrible system for a reproducibility-focused researcher. What would "reproducible deadline management" look like?
find_events from Day 11 shows me existing events. For creating, I'd call GOOGLECALENDAR_CREATE_EVENT with the calendar ID, a title, a start time, and an end time. All as ISO 8601 strings.
Exactly. The start and end times are nested inside dicts with a dateTime key — the Calendar API's way of distinguishing timed events from all-day events. One call, one deadline, one confirmation:
result = toolset.execute_action(
Action.GOOGLECALENDAR_CREATE_EVENT,
{
"calendar_id": cal_id,
"summary": title,
"start": {"dateTime": start},
"end": {"dateTime": end}
}
)
Why are start and end nested as {"dateTime": ...} instead of just passing the string directly?
The Calendar API uses the nested format to allow different event types. {"dateTime": "2026-05-30T09:00:00Z"} is a timed event. {"date": "2026-05-30"} (no time) is an all-day event. The wrapping lets the API distinguish them unambiguously. Always use dateTime for submission deadlines — you need the specific hour, not just the day.
I just pre-registered my submission calendar. In code. That's actually a methods contribution — reproducible deadline management.
The sticky note is retired:
def create_event(cal_id: str, title: str, start: str, end: str) -> dict:
result = toolset.execute_action(
Action.GOOGLECALENDAR_CREATE_EVENT,
{"calendar_id": cal_id, "summary": title, "start": {"dateTime": start}, "end": {"dateTime": end}}
)
print(f"Event created: {title}")
return result
I can run this three times for the three deadlines. The calendar event shows up with reminders, shared with my co-authors, no sticky note required.
Always test with your primary calendar first before creating events in a shared lab calendar. Creating a duplicate event in a shared calendar that your PI can see is the Calendar equivalent of sending to the wrong email recipient — visible to the wrong people at the wrong time.
toolset.execute_action(
Action.GOOGLECALENDAR_CREATE_EVENT,
{
"calendar_id": "primary",
"summary": "JPSP Submission Deadline",
"start": {"dateTime": "2026-05-30T09:00:00Z"},
"end": {"dateTime": "2026-05-30T10:00:00Z"}
}
)| Format | Event type |
|---|---|
{"dateTime": "2026-05-30T09:00:00Z"} | Timed event (specific hour) |
{"date": "2026-05-30"} | All-day event |
The ISO 8601 format YYYY-MM-DDTHH:MM:SSZ is required for dateTime. Missing the T or Z causes a validation error from the Calendar API.
Test with calendar_id: "primary" (your personal calendar) before using a shared lab calendar ID. Events created with the wrong calendar ID go to the wrong calendar and can't be recalled silently.
Three submission deadlines this quarter. Right now they're on a sticky note. You said on Day 9 that was a terrible system for a reproducibility-focused researcher. What would "reproducible deadline management" look like?
find_events from Day 11 shows me existing events. For creating, I'd call GOOGLECALENDAR_CREATE_EVENT with the calendar ID, a title, a start time, and an end time. All as ISO 8601 strings.
Exactly. The start and end times are nested inside dicts with a dateTime key — the Calendar API's way of distinguishing timed events from all-day events. One call, one deadline, one confirmation:
result = toolset.execute_action(
Action.GOOGLECALENDAR_CREATE_EVENT,
{
"calendar_id": cal_id,
"summary": title,
"start": {"dateTime": start},
"end": {"dateTime": end}
}
)Why are start and end nested as {"dateTime": ...} instead of just passing the string directly?
The Calendar API uses the nested format to allow different event types. {"dateTime": "2026-05-30T09:00:00Z"} is a timed event. {"date": "2026-05-30"} (no time) is an all-day event. The wrapping lets the API distinguish them unambiguously. Always use dateTime for submission deadlines — you need the specific hour, not just the day.
I just pre-registered my submission calendar. In code. That's actually a methods contribution — reproducible deadline management.
The sticky note is retired:
def create_event(cal_id: str, title: str, start: str, end: str) -> dict:
result = toolset.execute_action(
Action.GOOGLECALENDAR_CREATE_EVENT,
{"calendar_id": cal_id, "summary": title, "start": {"dateTime": start}, "end": {"dateTime": end}}
)
print(f"Event created: {title}")
return resultI can run this three times for the three deadlines. The calendar event shows up with reminders, shared with my co-authors, no sticky note required.
Always test with your primary calendar first before creating events in a shared lab calendar. Creating a duplicate event in a shared calendar that your PI can see is the Calendar equivalent of sending to the wrong email recipient — visible to the wrong people at the wrong time.
toolset.execute_action(
Action.GOOGLECALENDAR_CREATE_EVENT,
{
"calendar_id": "primary",
"summary": "JPSP Submission Deadline",
"start": {"dateTime": "2026-05-30T09:00:00Z"},
"end": {"dateTime": "2026-05-30T10:00:00Z"}
}
)| Format | Event type |
|---|---|
{"dateTime": "2026-05-30T09:00:00Z"} | Timed event (specific hour) |
{"date": "2026-05-30"} | All-day event |
The ISO 8601 format YYYY-MM-DDTHH:MM:SSZ is required for dateTime. Missing the T or Z causes a validation error from the Calendar API.
Test with calendar_id: "primary" (your personal calendar) before using a shared lab calendar ID. Events created with the wrong calendar ID go to the wrong calendar and can't be recalled silently.
Create a free account to get started. Paid plans unlock all tracks.