Resolve Semi-Annual Calendar Bug with Timezone SettingsResolve Semi-Annual Calendar Bug with Timezone Settings
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Here's a bug that ships to production silently and only shows up half the year.
You build an "Add to calendar" link. You test it in winter, it's perfect. Come summer, every event lands an hour off, and nobody can reproduce it on demand because whether it breaks depends on the date.
The cause: the link stamps the time as UTC (a trailing Z on the timestamp), but the time you actually stored is local wall-clock. Google dutifully reads your local time as UTC and shifts it by the offset. In the UK that offset is zero in winter and one hour in summer under BST, so the bug stays hidden for months.
The fix is two parts. Drop the Z so the time is "floating" with no zone attached, and add &ctz=Europe/London to the URL so Google places the event in London and handles the BST/GMT switch itself. Now the time you typed is the time the user sees, all year.
The rule underneath it: a timestamp with no timezone is ambiguous, and the classic mistake is labelling a local time as UTC. Decide explicitly whether your digits are UTC or wall-clock, and never let one pose as the other.
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started