The Hour That Happens Twice: Building UK Software That Survives the Clocks Change

Most UK software works perfectly for 363 days of the year. Then the clocks change, and a small but important set of features starts behaving strangely. An appointment appears twice. A night shift is paid incorrectly. A daily report covers 23 hours one day and 25 the next. These are not exotic edge cases. They are ordinary business events that occur because the product has treated local clock time as if it were a fixed, universal quantity.

The United Kingdom observes daylight saving time. In spring, clocks move forward by one hour; in autumn, they move back. The transition happens in the early hours of a Sunday, which makes it easy to ignore during normal working hours and easy to miss in testing. For product teams, however, the consequences can surface in customer-facing bookings, payroll calculations, recurring appointments, service-level reporting and financial reconciliations. Time is not a formatting concern. It is a product requirement.

Why local time is a seductive default

Many systems store a date and time exactly as a user types it: 2026-10-25 01:30, for example. That looks precise, but it is not a complete fact. On the autumn transition date, 01:30 in London occurs twice. Once in British Summer Time and once in Greenwich Mean Time. Without an offset or a time-zone rule, the system cannot tell which instant is meant. On the spring transition date, 01:30 does not occur at all, because the clock jumps from 01:59 to 02:00.

This ambiguity is manageable for a human reading a wall clock. It is not manageable for software that schedules reminders, calculates elapsed time, applies cut-off rules or aggregates activity by day. If the database stores local wall-clock time without context, the application is relying on an assumption that is false twice a year.

The problem is compounded by common defaults. A server may run in UTC while a database column has no time-zone information. An export to CSV may drop offsets. A third-party calendar integration may accept local times but interpret them in a different zone. Each of these small decisions makes the system less able to answer a basic question: when did this actually happen, and when should the next action occur?

Three failures UK teams should recognise

The first is the booking and scheduling failure. A customer books a slot at 01:30 on the autumn transition date. The system stores the local time, sends a confirmation and creates a reminder. Because the time is ambiguous, the reminder may fire at the first occurrence, the second occurrence or neither, depending on how the scheduling library resolves the ambiguity. For a clinic, garage, delivery service or professional-services firm, a missed or duplicated appointment is a visible service failure.

The second is the payroll and timesheet failure. Consider a shift that runs across the autumn transition. A simple subtraction of clock times may produce nine hours when ten were worked, or the reverse in spring. The same issue affects overtime, rest-period calculations and agency billing. Payroll errors are particularly damaging because they undermine trust and can create compliance questions.

The third is the reporting and service-level failure. A daily sales report, support dashboard or operational summary usually assumes that a day contains 24 hours. On transition days, a Europe/London day may contain 23 or 25 hours. If the product calculates daily totals using local midnight boundaries without accounting for the offset change, the figures can be misaligned with the business definition of a day. The result is not merely a technical curiosity. It can distort month-end reporting, capacity planning and performance against service-level agreements.

A plain-English checklist for UK product teams

Store instants in UTC, and store local rules where they belong

For events that have already happened, or for any timestamp that represents a precise instant, store UTC. Use a database type that preserves the offset, such as timestamptz in PostgreSQL, or store ISO 8601 values with an explicit Z or offset. Convert to local time only at the edges of the system: in the user interface, in reports and in integrations that require local time.

Future events need a little more care. A recurring appointment at 09:00 every Monday in London should remain at 09:00 local time even after the clocks change. If the product stores only a UTC instant, that appointment will drift by an hour. The practical pattern is to store the local date and time together with the IANA time-zone identifier, then resolve the exact instant when the event is scheduled or displayed. The key is to avoid storing an incomplete local timestamp without a zone rule.

Pin the time zone to Europe/London

Do not rely on the server's default time zone. Do not use fixed abbreviations such as GMT or BST as though they were interchangeable. Use the IANA identifier Europe/London, which contains the full set of historical and future transition rules. Where users operate across multiple regions, store their preferred zone explicitly and show it in the interface. A UK business may be small, but its software can still be used by staff, suppliers or customers in other countries.

Treat both transitions as test cases

The spring and autumn changes should be part of the regular test suite, not a manual check performed once by a developer. Test the periods around 01:00 to 02:00 local time on the relevant Sundays. Include booking creation, reminder scheduling, recurring events, payroll calculations, daily reporting and any cut-off rules. Use a fixed clock in automated tests so that the scenarios are repeatable. If the product has an API, test how it accepts and returns timestamps with offsets. If it integrates with calendars, test the round trip.

Make time visible in the interface

Users should not have to guess which time zone a value belongs to. Show the zone and, where useful, the current offset. A label such as 10:00 GMT (London) is clearer than a bare time. For ambiguous times on the autumn transition date, the interface should ask the user to choose the first or second occurrence, or state clearly which one the system will use. For nonexistent times in spring, the product should reject the value or shift it with a clear explanation. Silence is the enemy here.

Schedule background jobs with the same care

A nightly job that runs at 01:30 local time may run twice, skip a run or collide with itself during a transition. Prefer scheduling in UTC where the business rule allows it. Where a job must follow local time, use a time-zone-aware scheduler and make the job idempotent. A job that sends reminders or posts invoices should be safe to run more than once. Logs should record both the UTC instant and the local time so that investigations are straightforward.

Designing for the hour that happens twice

The most important design decision is to separate the instant from the wall-clock representation. A booking system may need to show a slot as 01:30 on the autumn date, but it must also know whether that means the first or second occurrence. A payroll system should calculate elapsed time from actual instants, not from a subtraction of local clock values. A reporting system should define day boundaries in Europe/London and accept that some days are 23 or 25 hours long. These are not compromises. They are accurate models of how UK time works.

For product teams, the practical question is not whether the software uses UTC or local time. It is whether the system has an explicit, testable answer for every time-related business rule. Where is the instant stored? Which zone governs the display? How are recurring events anchored? What happens at the transition? If those questions have clear answers, the clocks change becomes an ordinary scheduled event rather than an annual risk.

Go Develop works with UK organisations on product engineering and digital transformation. The most reliable systems are not the ones that ignore complexity, but the ones that make complexity visible and manageable. Daylight saving is a good example. It is a small part of the calendar, but it is a useful test of whether a product has been designed with real business operations in mind.