Scheduling texts around the clock change

At 02:00 on Sunday 25 October 2026, every clock in the UK will go back to 01:00 and run through the same hour a second time. Eight days from now, as this is written. A text scheduled for 01:30 that morning has two moments it could mean, an hour apart. The opposite happened on Sunday 29 March, when the clocks jumped from 01:00 straight to 02:00 and a text scheduled for 01:30 had no moment at all. Twice a year, for one hour, "a time in London" stops being a single instant, and any system that stores schedules as local times has to have an answer ready.

Most of the year you can ignore all this. A reminder set for 09:00 goes at 09:00. The trouble arrives in two forms: the hour that goes missing or repeats, and the quieter problem that every "09:00 London" after the change is a different number of hours from UTC than it was the day before. Both have clean fixes, and the fixes come from three places: the Act that sets the dates, the database that encodes them, and two RFCs that say how to write a time down.

What the law says

Section 1(1) of the Summer Time Act 1972 says that the time for general purposes in Great Britain shall, during the period of summer time, "be one hour in advance of Greenwich mean time". Section 1(2) defines the period, and the current wording was put there by the Summer Time Order 2002 (S.I. 2002/262, made on 12 February 2002 and in force from 11 March 2002): summer time is "the period beginning at one o'clock, Greenwich mean time, in the morning of the last Sunday in March and ending at one o'clock, Greenwich mean time, in the morning of the last Sunday in October".

Read that carefully, because it explains a thing the gov.uk page describes differently. Gov.uk says the clocks "go forward 1 hour at 1am on the last Sunday in March" and "back 1 hour at 2am on the last Sunday in October". The Act says both changes happen at one o'clock Greenwich mean time. They agree: at the end of October the UK is on BST, and 01:00 GMT is 02:00 BST. The change is the same instant in both directions, 01:00 UTC. Only the local label differs. That single fact, that the switch is defined in GMT and only looks like 2am from inside summer time, is most of what a developer needs.

The dates move because "last Sunday" moves. Gov.uk lists 30 March and 26 October for 2025, and 29 March and 25 October for 2026. The page calls the period "British Summer Time (BST)" and the rest of the year "Greenwich Mean Time (GMT)", and it was last updated on 24 November 2025.

The hour that goes missing, and the hour that repeats

In March, local time runs 00:59:59 GMT and then 02:00:00 BST. Nothing in London is ever stamped 01:00:00 to 01:59:59 that morning. Hand a scheduler "2026-03-29 01:30" with no offset and it has to invent an answer, and libraries differ: some push the time forward to 02:30 BST (which is 01:30 UTC, so the text goes at the instant the clock face would have shown 01:30 had it existed), some push back to 00:30 GMT, some refuse. Across three services you can get three answers, and nobody notices until a customer asks why a reminder arrived an hour early.

In October, local time runs 01:59:59 BST and then 01:00:00 GMT. Every clock reading from 01:00:00 to 01:59:59 occurs twice: first with offset +01:00, then with offset +00:00. "2026-10-25 01:30" is a real time, twice. A scheduler that stores it as a local string will fire it at the first 01:30, or the second, or (the worst case, and a real one) both, if the job runner wakes up each minute, compares the clock to the stored string, and sees a match twice.

For marketing this is less dangerous than it sounds, because both hours sit inside the window nobody should be texting in. CaptiFi Connect's campaign quiet hours default to 21:00 to 09:00 London time, and the same is sensible for anyone. The texts that do get scheduled overnight are the automatic ones: a code, an alert to on-call staff, a "your table is in 24 hours" reminder computed from a booking, a batch of appointment reminders set to go at 07:00. Those are the ones to check.

The broader effect is simpler and catches more people. A reminder that should go at 09:00 London on Saturday 24 October goes at 08:00 UTC. The same 09:00 London on Monday 26 October is 09:00 UTC. A system that converted "09:00 London" to UTC once, when the schedule was created, and stored only the UTC instant, will send Monday's text at 10:00 London. The customer sees a reminder an hour late every weekday until someone fixes it, and then the same thing in reverse at the end of March.

What the tz database encodes

The rules a computer uses to turn "09:00 London" into an instant come from the IANA Time Zone Database, "often called tz or zoneinfo". The IANA page lists release 2026e, dated 29 September 2026, and the companion tz-link page says plainly that "there is no fixed schedule for tzdb releases". Every operating system, language runtime and database ships a copy, which is why an unpatched server can disagree with a patched one about what time it is somewhere.

The UK's entry is short enough to read in full. In the source file, the zone Europe/London is five lines: local mean time, 1 minute and 15 seconds behind Greenwich, until 1 December 1847; GMT with the "GB-Eire" rules until 27 October 1968; then an hour ahead, all year, labelled BST, until 02:00 UTC on 31 October 1971; GB-Eire rules again until 1996; and since then GMT with the "EU" rules. Those EU rules are two lines: summer time starts on the last Sunday in March at 01:00 UTC, and ends on the last Sunday in October at 01:00 UTC, "max" in the year column, meaning until further notice. That is the Summer Time Order 2002 in machine form.

The 1968 to 1971 block is the one to notice. The source file comments it as "The British Standard Time Act, 1968 (no summer time)": the country stayed an hour ahead of Greenwich through three winters and the database still has to know, because a timestamp from January 1970 in London was +01:00. The file's own abbreviation table lists BST twice, once as "British Summer" and once as "British Standard (1968-1971)", which is the neatest example going of why the tz-link page warns that "alphabetic time zone abbreviations should not be used as unique identifiers for UT offsets as they are ambiguous in practice". Use the zone name, Europe/London, and the database does the rest. The same file adds, in a comment: "Use Europe/London for Jersey, Guernsey, and the Isle of Man", which settles the question for everywhere CaptiFi Connect sends to.

Before 1981 the UK's own rules changed the time at "2:00s", two o'clock standard time, and the dates wandered: the third Sunday in March or later for 1972 to 1980, the Sunday on or after 23 October in autumn. From 1981 the change moved to "1:00u", one o'clock universal time, which is where it has stayed. A scheduler that hard-codes "2am" is encoding a rule that has been wrong since 1981.

Writing a time down so it survives

RFC 3339, from July 2002, is the format behind almost every API timestamp. Its position on bare local times is blunt: "the interoperability problems of unqualified local time are deemed unacceptable for the Internet". A timestamp carries either "Z", which the RFC defines as "a suffix which, when applied to a time, denotes a UTC offset of 00:00", or a numeric offset written as a sign, hours and minutes, calculated as "local time minus UTC". So 2026-10-25T09:00:00Z and 2026-10-25T09:00:00+00:00 are the same instant, and 2026-10-24T09:00:00+01:00 is 08:00 UTC the day before. The RFC also says, in its first section, that the UTC time for a locally scheduled event "may depend on administrative decisions about daylight savings time", and then leaves that problem to the application. That is the gap the clock change falls into.

RFC 9557 (2024) fills it. It adds an optional bracketed suffix carrying the zone name, so a timestamp can read 1996-12-19T16:39:57-08:00[America/Los_Angeles], which is the RFC's own example. The offset fixes the instant; the zone name supplies the rules for anything calculated from it, such as "the same time tomorrow". The two can disagree, and the RFC gives 2022-07-08T00:14:07+01:00[Europe/Paris] as an inconsistent example, because Paris was on +02:00 that July; a receiver may ignore the zone and trust the offset, unless the sender marks the tag critical with an exclamation mark, in which case the receiver must deal with the conflict.

Put those together and the rule for a scheduled text is: store the local time and the zone name as the thing the customer asked for, work out the instant with the tz database when the send is created, and send the API the instant with an explicit offset. Never send 09:00 and hope.

Scheduling texts safely

Decide which kind of schedule each text is. An appointment reminder is a local time: the customer booked 10:30 on a Monday in London and expects the reminder the day before at a London hour. A code or an alert is an instant: now, or sixty seconds from now, with no clock face involved. A "send 24 hours before" is an instant computed from a local time, and the 24 hours is in UTC, which across the October change means 25 local hours and across March means 23. Decide which you mean and the rest follows.

Keep the local time and the zone. The UTC you derive from them changes twice a year, so if the practice manager moves every Monday reminder to 08:30, you want "08:30 Europe/London", recomputed per occurrence. A recurring schedule stored as an instant is the usual cause of the hour-late reminder.

Make the two bad hours impossible to reach. Refuse a local time that does not exist in March, or map it forward to the next valid minute and say so. For the repeated hour in October, choose the first occurrence and document it, or (better) keep scheduled customer texts out of 01:00 to 02:00 altogether; quiet hours do that for campaigns, and a one-line check does it for everything else.

Give the API the instant. CaptiFi Connect's scheduled sends take an ISO 8601 time with its offset, so 2026-10-26T09:00:00+00:00 goes at nine on the Monday after the change and 2026-10-23T09:00:00+01:00 goes at nine on the Friday before, and neither depends on which side of the switch the request was made. Pair each with an Idempotency-Key, as our API docs describe, so that a job runner which fires twice across the repeated hour still creates a single text.

Run the servers in UTC and convert at the edges. A cron entry at 09:00 on a server set to Europe/London will skip or double on the two Sundays; the same entry on a UTC server never does, and the conversion to a London hour happens where the customer's schedule is read.

Finally, test the four moments. 00:59 and 02:00 on the last Sunday in March, 01:59 and 01:00 (the second one) on the last Sunday in October. Write the test once with Europe/London in the zone column and it keeps working when the dates move, which under the Act they do every year: 28 March and 31 October in 2027, by the "last Sunday" rule the 2002 Order wrote in.