Understanding UK Time Without the Headache
The UK uses two time standards throughout the year, and most people only learn about them when something breaks. GMT is the baseline. BST is what happens from late March to late October when clocks move forward one hour. The zone identifier for both in every system that matters — databases, servers, APIs — is Europe/London. That single string handles the entire switch automatically if you use it correctly. I spent three years managing scheduling systems for a logistics company that spanned the UK, Ireland, and parts of mainland Europe. One Tuesday in 2019, a client reported that their Monday morning reports were generating at 11 PM instead of 9 AM. Two hours off. We checked every config file. Everything looked right. The issue turned out to be a Python script that was storing timestamps in UTC but displaying them using the system local timezone, which had been set to Europe/Dublin on a staging server. Europe/Dublin and Europe/London are effectively the same offset year-round, but they are not interchangeable in code that relies on named zones. Once we swapped it to Europe/London consistently across the board, the problem disappeared. That taught me to never assume two zones with the same offset are functionally identical. Here is how the actual mechanics work. GMT, or Greenwich Mean Time, is UTC+0. It does not change. BST, British Summer Time, is UTC+1. The transition dates follow EU rules, even though the UK has left the EU. The current schedule keeps BST in effect from the last Sunday in March at 1 AM GMT until the last Sunday in October at 1 AM BST. During the switch, the clock jumps from 1:00 AM to 2:00 AM. Any code that parses or generates times around that window needs to handle the gap properly, or you will get invalid timestamps.
The Europe/London zone identifier is what you should use in PostgreSQL, MySQL, JavaScript, Python's zoneinfo, Java's ZoneId, and basically every major platform. Do not use GMT as a timezone identifier in your application logic unless you specifically mean the static offset with zero daylight saving awareness. GMT in most libraries is treated as UTC+0 fixed, which means it will not shift to BST. That is the most common mistake I see. People write code that works perfectly from November to March and then something breaks in spring because they hardcoded a static offset instead of using a proper zone. If you are building something that schedules events, sends emails, or logs activity for UK users, store everything in UTC internally. Convert to Europe/London only at the point of display. This eliminates half the bugs that come from dealing with transitions. When you do convert, always go through UTC first. Skipping that intermediate step introduces subtle errors around the switch days. There is a scenario that catches almost everyone out at least once. The UK has multiple clock transitions in a single calendar day on the Sunday when the change happens. In the fall, the clock goes back from 2 AM BST to 1 AM GMT, creating an hour that repeats. If your system receives an event timestamp without an explicit UTC offset or zone identifier during that window, it becomes ambiguous whether it refers to the first occurrence or the second. I ran into this when integrating a payment gateway that sent webhook timestamps in naive local time. We lost three transaction reconciliation reports one October because the timestamps between 1 AM and 2 AM could not be disambiguated. The fix was simple but easy to miss: require the gateway to send ISO 8601 timestamps with explicit offsets. They refused to change their integration spec, so we wrote a resolver that treated all ambiguous times as belonging to the post-transition GMT period. It was the only reasonable default given the constraints.
Another thing nobody mentions often enough: the Channel Islands and the Isle of Man follow the same time rules as the UK but are sometimes geolocated incorrectly in address databases. If your system routes something based on timezone derived from IP geolocation, it can end up placing Jersey or Guernsey in a generic Western European zone that may or may not observe the same DST schedule depending on the database version. This is an edge case that only matters if you are doing anything precise like compliance logging or audit trails spanning the entire British Isles. If you need to generate human-readable time references quickly, many environments support the zoneinfo database directly. On Linux and macOS systems, the IANA timezone database is built in. You can verify what Europe/London resolves to on any given date with a simple command or query. On Windows, things are messier. The system uses its own mapping between IANA names and Windows timezone identifiers. Europe/London maps to GMT Standard Time on Windows, and that mapping has historically been unreliable when Microsoft updates the OS time zone definitions. I have seen production servers where a Windows update silently reclassified the timezone and caused a whole week of scheduling drift before anyone noticed. The main downside to relying on Europe/London as your canonical identifier is that not all legacy systems support IANA zone names. Some older .NET applications, certain mainframe environments, and a lot of embedded firmware still expect numeric UTC offsets. In those cases you have to maintain your own translation table and recalculate offsets around DST transitions manually. It adds maintenance overhead and introduces a class of bugs that is extremely difficult to trace because the error manifests only during transition weeks. If you are stuck with a system like that, consider adding a periodic validation job that runs on the day before and after each clock change to catch any discrepancies early.
Get the Full Details
For most practical purposes, the rule is straightforward: use Europe/London everywhere, store in UTC, convert at the boundary. Anything more complicated than that usually means the architecture is doing something unnecessary.
