What actually happens when you convert UK time to European time
Most people think it's always one hour difference. It isn't. The UK runs GMT in winter and BST in summer. Continental Europe runs CET and CEST. They don't switch on the same day, which creates a two week window every spring and autumn where the gap shifts by an hour. Here's the practical rule of thumb. During standard time, London is UTC+0 and Paris/Berlin/Rome are UTC+1. One hour behind. When BST kicks in, the UK jumps to UTC+1 while continental Europe stays on UTC+1. Same offset. Then a few weeks later Europe moves to UTC+2 and suddenly the UK is an hour behind again. The same pattern reverses in autumn.UK To Et Navigating The Complex World Of UK To Euro Time Conversion
The DST overlap period is where people mess up. In spring, the UK moves forward on the last Sunday of March. The EU moves forward on the last Sunday of April. That means between those two dates, there is zero hour difference. London and Berlin are on the same time. If you're scheduling a call or setting a deadline during that window and you subtract one hour like normal, you're an hour off. I learned this the hard way in 2019. I was coordinating a video shoot between our London office and a post-production house in Munich. I had the edit suite booked for 14:00 Munich time on March 31st. I booked the London crew for 13:00, assuming the one hour gap. Turns out that year the UK had already switched to BST but Germany was still on CET. Same time. We spent forty five minutes waiting around before someone figured out what happened. The workaround was simple, just check both timezones against each other directly instead of relying on memory, but the lesson stuck. In autumn the reverse happens. The EU switches back first, usually the last Sunday in October. The UK follows about three weeks later. Between those dates the gap briefly becomes two hours before snapping back to one. Again, most people don't notice until something breaks.
How to convert reliably without thinking about it
The safest approach is to never convert mentally. Use a tool. Most calendar apps handle this automatically if you add both timezones. When I schedule anything between UK and EU contacts now I just put both times visible in the invite. London 09:00 / Berlin 10:00. Everyone sees the conversion. Nobody has to do math. If you're doing this programmatically, use the IANA timezone database. Never use fixed offsets like +01:00 or +00:00 in your code. Those are ambiguous. Use Europe/London and Europe/Berlin and let the library resolve the offset for the specific date. Python's zoneinfo module, JavaScript's Intl.DateTimeFormat, Java's ZoneId, all of them work correctly when you give them the city name instead of a raw offset. Here's a quick Python snippet that shows the actual offset for any given date:
zoneinfo.ZoneInfo("Europe/London") and zoneinfo.ZoneInfo("Europe/Berlin") both return the correct UTC offset for any date you pass them, including the edge cases around DST transitions.
Get the Full Details
Edge cases you should know about
Portugal is in the EU but runs Western European Time, same as the UK. Lisbon is UTC+0 in winter and UTC+1 in summer, exactly matching London. If you're converting London to Lisbon time the answer is always zero difference. People assume Portugal is one hour ahead because it's on the continent. It isn't. Finnland, Greece, and Turkey follow Central European Time in winter but Turkey stopped observing DST in 2016. They stay on UTC+3 year round. So in summer the gap between London and Istanbul is two hours, not one. In winter it's three hours. This trips up anyone who looks at a map and assumes geographic proximity means timezone proximity. Another gotcha: the UK and EU DST rules are now legally separate. The EU harmonized its rules in 2019, but the UK left the framework. Currently they still align because the legislation is identical, but there's no guarantee they'll stay that way. The EU has discussed moving to permanent summer time, though nothing has happened yet. If that ever goes through, the conversion rules change fundamentally and everything you've memorized becomes wrong overnight.
When tools fail
Some older scheduling platforms hardcode the one hour difference. If you're using something ancient that just subtracts one hour from EU times without checking the date, it will be wrong during the overlap windows I mentioned. Always spot check a date that falls in late March or late October against a known correct source like timeanddate.com before trusting the output. The conversion itself is trivial. The edge cases are what cost you time. Keep both timezones visible in your invites, use proper IANA names in code, and check late March and late October dates manually if you're doing something important.
