Scheduling Across The Atlantic Is More Painful Than The Math Suggests
Pacific Standard Time is eight hours behind Greenwich Mean Time, and during the summer months when both places shift clocks, it drops to seven. That simple number hides most of the actual problems people face when trying to coordinate work across the ocean. The difference is not the hard part.figuring out when someone is actually available to talk is where everything falls apart. I spend most of my week booking calls between San Francisco and London, and the overlap window is smaller than anyone expects. When both cities are on standard time, California runs from 8 AM to 5 PM Pacific, which translates to 4 PM to 1 AM London time. The usable overlap is roughly 8 AM to 5 PM California, which is 4 PM to 1 AM in London. That gives you a four-hour window where both sides are working normal business hours, and honestly that is generous compared to what some people deal with Tokyo or Singapore. When daylight saving hits, things shift again. The US moves forward on the second Sunday in March, but the UK does not change clocks until the last Sunday in March. For about a week every spring, California is six hours behind London instead of seven. Every fall, the UK ends DST on the last Sunday while California keeps going until the first Sunday in November, so for roughly one week the gap widens to eight hours again. Both transitions cause confusion if you are not watching the calendar closely. I lost a client meeting once because I assumed the shift had happened in London and showed up an hour early on a Zoom link that nobody else had opened yet. That burned six weeks of scheduled rapport with a prospective partner.
The practical workaround is straightforward and saves a lot of wasted back-and-forth. Keep a shared calendar entry labeled in both time zones, and always include the UTC offset in meeting invites instead of relying on the invitee's device to convert correctly. Something like 10:00 AM PST (18:00 GMT, +00:00) removes most ambiguity. Most scheduling tools default to the creator's local time, which means the person on the other side of the ocean sees a converted slot that can drift if their device has auto-update delays or if they are traveling through a different zone without updating their calendar app. There is a deeper issue people miss. The eight-hour gap sounds symmetrical, but it is not in practice because meeting culture on each side of the Atlantic skews toward different parts of the day. London teams tend to push afternoon calls toward early slots, which land in the late morning for California. American teams often assume a 2 PM California time works fine for a 10 AM London start, but by the time the call actually gets on the books, it has drifted to 3 PM Pacific, which is 11 AM London, and suddenly the British side has cut into their post-lunch groove. The reverse happens too. London meetings at 3 PM hit California at 7 AM, which is fine for one-off syncs but unsustainable for recurring calls. After three weeks of 7 AM starts, productivity drops noticeably across the team. People show up groggy, and decisions made at that hour tend to get revisited anyway. If you are managing distributed teams long-term, the most reliable solution is rotating the inconvenience. Do not force California to bear the early mornings every single week. Switch the recurring slot monthly, or keep a core synchronous window that lands around 9 AM to 11 AM Pacific and 5 PM to 7 PM London, which is acceptable on both sides if it is not a daily requirement. Anything beyond that tends to breed resentment quietly. Nobody announces it, but attrition rates climb in teams where one region consistently carries the worst schedule penalty.
Another thing worth noting is that daylight saving dates have drifted over time, and different countries handle the transition differently. The US and Canada follow the modern DST schedule established in 2007, but the UK and most of Europe have kept their own rules since 1996. The misalignment weeks happen annually, and relying on automatic conversions in Outlook or Google Calendar during those transition periods produces roughly a five percent error rate in my experience. Not catastrophic, but enough to waste twenty minutes rescheduling things manually. For tools, I recommend Time.is for quick manual checks, but for actual coordination, a shared world clock widget embedded in your main workspace chat reduces friction significantly. Slacks has a built-in timezone-aware reminder feature, and Google Calendar shows overlapping free/busy across zones if you enable multiple time displays. Neither is perfect. Manual verification still takes about two minutes per meeting invite, but that two minutes prevents the kind of domino failures that happen when three people are in three different zones and the fourth person sent the wrong conversion. The real bottleneck is not knowing the offset. It is keeping track of when that offset changes and how the changed offset reshapes everyone's working day. Once you lock down a consistent scheduling routine and stop letting calendar apps auto-convert without a second check, the transatlantic gap becomes manageable rather than exhausting. Most teams I work with stabilize within a month of switching to explicit UTC notation on every invite. After that, the conversations just happen.
Get the Full Details
