What Broke When I Tried Planning My Week with Calendar Apps

1. Blocking time on Google Calendar fails when full-day events exist

If you’re using Google Calendar to block time across multiple days and you’ve also got a recurring all-day event (like a birthdays calendar or shared company holiday calendar), it’s going to mess with your visual layout more than you’d think. I had a repeating full-day “Tech Debt Thursday” event that wasn’t even a real meeting, just a placeholder. But every time my script tried inserting 2-hour deep work blocks, it skipped Thursdays even when I was totally available. No warning, no error. Just silently skipped.

The Google Calendar API treats allDayEvent: true as occupying the entire day — even if you’re booking in hourly mode. That single checkbox in another calendar caused my time-blocking script to misinterpret the entire day as unavailable. There’s no toggle to override this when inserting events through automation — you have to fetch and filter out full-day events manually.

Workaround ended up being painfully manual: loop over list.events, discard anything without start.dateTime, and replot the blocks safely. Just assume anything missing timezone data is blocking your whole day whether you asked for it or not.

2. Calendar availability APIs lag by several minutes or more

I used Clockwise for a few months and it’s magical until you’re triggering updates from another app like Notion or Slack and expect your calendar to update instantly. It doesn’t. I once had a 1-on-1 rescheduled via a Slack bot, with the expectation that my Clockwise-managed time blocks would shift to accommodate it. Result: overlapping events, passive-aggressive reschedule pings, and me manually dragging green blocks back and forth like a human diff tool.

Here’s the underlying issue: platforms like Clockwise, Reclaim, and even Google’s Apps Script don’t treat your calendar as having true “last-write-wins” state. They batch process updates. So if your automation sends 3 changes in under a minute, some might get dropped or coalesced. There’s rarely a webhook on successful move.

Useful thing I learned from a Reclaim support thread: background syncing has a hard-coded delay — sometimes up to 10 minutes based on your activity level. Not documented anywhere. But if you view your calendar, it refreshes immediately. So just clicking into the page can affect automation timing. Yeah.

3. Notion calendars do not respect timezones on imports or exports

It took me an embarrassing amount of time to realize that most of my Notion-based planning wasn’t actually aligned to my real-world schedule. When you link a Notion database to a calendar integration (via Zapier or Make), the timezone behavior of “created” and “last edited time” fields is entirely contextless unless you set up conversion yourself.

One time I copied over a week of planning items into Google Calendar and every task was off by an hour. Turns out Notion stores all internal date properties in UTC and doesn’t apply any shift unless there’s a user-facing Date field with time included. Even then, displaying local time in Notion doesn’t carry over when the automation sends the data elsewhere.

I ended up adding a helper formula column showing converted times using dateAdd(prop("Time"), -5, "hours") just to visualize how off things were. But if you try to use that value downstream in a Make scenario, it’s read as text, so Timezone bleeding is inevitable unless you explicitly re-cast it at each step. Seriously annoying.

4. Using AI to draft weekly plans usually overbooks you by Wednesday

I tried using ChatGPT to generate a rough draft of my workweek. Prompted it with current project themes, key meetings, and hours available. Evening time was marked for overflow. Looked solid on paper. By Wednesday noon, the AI’s plan had me in three overlapping focus blocks, back-to-back meetings, and a daily review scheduled precisely when I’m usually on lunch.

AI planners (even fancy ones in tools like Motion or Reclaim) almost always assume linear execution and zero fatigue. There’s no “recovery window” unless you dictate it. I changed my prompt to include max X hours of heads-down time per day, said I needed recovery blocks after back-to-back meetings, and illegal config errors started popping up (“unable to place task”).

“Task cannot be scheduled unless dependencies are relaxed or work hours are extended.”

That’s Motion’s AI planner giving up mid-schedule. Once you constrain rest and buffer, your plan just fails to generate. Which is… revealing.

5. Working hours logic breaks if you adjust sunlight settings

Here’s one from someone deep in the iOS ecosystem: if you use Apple Calendar and have “Time to Leave” enabled based on location/sunlight prediction, and modify your working hours range in Screen Time settings, you can watch the system start delaying or misplacing events.

I moved my work hours from 9–5 to 10–6 (I like quiet mornings). The calendar auto-shifted a recurring 9:30 Monday meeting to “tentative” without asking. Turns out, as a privacy measure, Apple deprioritizes non-Working Hour events when locations shift sunlight predictions — say, you start working from a new Wi-Fi location.

I caught it because a recurring client sync failed to show up on my CarPlay dashboard. I double-checked on desktop, and it was there, but ghosted out. If a calendar bot had been pulling availability from that view, it would have looked empty.

There’s no alert, no app prompt. The fix was opening the meeting, re-confirming the time manually, and watching it reappear on all synced devices. Every calendar source uses its own sense of priority. Apple’s mixes in environment detection. Don’t trust sync alone.

6. Zapier creates duplicate calendar events if filter delays happen

I had a Zap that auto-creates calendar events whenever a Notion page is moved into a “Scheduled” column. Worked beautifully during testing. But then I hit a weird sync delay while moving 12 tasks into that column in bulk. Zapier lagged, assumed multiple new triggers, and fired the same event insert four times for some records.

If you have a multi-step Zap that uses a filter before the calendar creation step, Zapier sometimes caches incoming data before the filter has passed, and if something glitches — like switching between tabs mid-move — it can duplicate triggers with the same timestamp. You’d think deduplication handles it. It doesn’t. Not when record IDs look close but not identical due to versioning in Notion or reordering.

Fix was adding a delay plus a custom dedupe step (passed through Formatter or via storage key logic). Honestly, that piece took longer than the whole rest of the Zap. At one point I had a Google Calendar with six “Project Proposal Review” events, all stacked and invisible unless you dug into All-day view. Brutal.

7. Dragging tasks into Fantastical can reset their completion state

In an attempt to make Sunday planning more tactile, I started dragging completed Todoist tasks into Fantastical as calendar entries just to reflect what got done. Felt satisfying. Way better than just archiving.

Then something weird started happening: previously completed Todoist tasks reverted to “Incomplete” after the drag-and-drop, because the automation (I was using Hookmark to link tasks, plus AppleScript triggers) parsed the action as a duplicate task creation. Todoist thought I was reopening the original because I’d passed the task URL under the hood.

This is undocumented behavior, but if you re-insert a task with the same URL or UID from the task source, and omit the completion step during automation, the system assumes you’re reopening it. It’s not a calendar bug — it’s a reference loop.

Eventually fixed it using Apple Shortcuts with a scriptable wrapper that strips all metadata except for title and timestamp before passing it into the calendar. Which breaks linking, but preserves task state. Can’t have both.

8. Sharing calendars across teams revives old events unexpectedly

This one burned me during a team offsite. We finally agreed to use a shared Google calendar for logistics. I made all-day events for travel days, added location links, and toggled “All-day.” Worked fine until someone added a Slack integration that synced calendar events to an events channel. Suddenly, old events from six months ago re-posted themselves to the channel.

Timeline looked like this:

• ~6AM: Edited an old event to fix a recurring typo
• ~6:03AM: Slack bot reposted it as a new event
• ~6:10AM: Five other archived events also reappeared

The issue wasn’t the calendar — it was the Slack bot’s webhook logic. It treats any update to a visible event as a new creation if the internal event UID has changed. Which can happen silently when you move an event to a shared calendar. UID regeneration without visibly editing the event is possible. There’s no flag to suppress it either.

Only fix I found, short of turning off event edits, was rate-limiting sync bots to ignore events older than X days based on custom metadata. But you have to insert that metadata yourself — Google Calendar doesn’t expose arbitrary record updates in the API without OAuth playground gymnastics.