On the night before the last Sunday in October, every interface between a shop and an ERP system is handed an extra hour that nobody ordered. The hour count moves back from 3 a.m. to 2 a.m., and the hour from 2 to 3 o'clock occurs twice (Federal Ministry of Justice). For a calendar that is a footnote. For a delta query that fetches every order changed since the last run, it is a data error without an error message: one run pulls the same documents twice, another skips them, and both report success. This article shows where timestamps arise in an ERP integration, which fields have to carry an offset, and what a test plan for that night looks like. Anyone connecting ERP and shop in wholesale decides at this point whether the changeover stays an entry in the calendar or becomes an incident in support.
Key takeaways
- Central European Summer Time ends on the last Sunday in October at 3 o'clock, the hour count moves back to 2 o'clock, and the hour from 2 to 3 o'clock occurs twice (Federal Ministry of Justice).
- The German ordinance names the two hours explicitly, 2A and 2B (Federal Ministry of Justice) – a local timestamp without an offset cannot tell them apart.
- The European rule sets the switch point at 1 a.m. Universal Time (Publications Office of the European Union), so every member state switches at the same instant.
- The internet standard RFC 3339 recommends Coordinated Universal Time for interoperability across system boundaries (RFC Editor), because local rules can change at unpredictable times.
- Delta queries and job schedules belong on UTC: otherwise one run reads the doubled hour twice, and in spring a run asks for a local time that does not exist on that day.
- The zone data release is a dependency with a date: six releases of the time zone database appeared between January 2025 and July 2026 (IANA).
What really happens in the doubled hour
The changeover is not a jump in time, it is a jump in labelling. Coordinated Universal Time runs on without interruption; what changes is the distance at which the local clock points to it. Legal time in Germany is Central European Time, defined as Coordinated Universal Time plus one hour (Federal Ministry of Justice); during summer time it is two hours (Federal Ministry of Justice). In October that distance falls from two hours to one, in March it climbs back.
Two special cases follow, and they hurt an interface in different ways. In October one local time belongs to two different instants: 2:30 exists twice, once with the offset +02:00 and once with +01:00. In March one local time belongs to no instant at all, because the hour count is moved forward from 2 o'clock to 3 o'clock (Federal Ministry of Justice) – 2:30 does not exist on that day. A date-and-time field without a zone cannot resolve the first case and cannot reject the second. It accepts both values and passes them on exactly as they arrived.
Event time in the shop
Order receipt, payment confirmation and status changes arise in the customer's browser, in the payment process and in the shop itself – three clocks that may well disagree. Where sequence matters, server time in UTC is the value to rely on, not the display in the account.
Posting time in the ERP
The ERP system writes change timestamps onto items, prices and documents. Whether those hold UTC or local time is decided by the database configuration, not by the interface – which is why the question belongs answered before the first import.
Run time of the interface
Every run has a start instant, a watermark of the last change read, and a window in the schedule. These three values are operating data, not business data, and they belong on UTC throughout.
The rule that sets the instant
The date is fixed in two texts that mean the same thing and phrase it differently. The German summer time ordinance puts it from the point of view of the clock on the wall: Central European Summer Time ends on the last Sunday in October at 3 o'clock Central European Summer Time (Federal Ministry of Justice), and it begins on the last Sunday in March at 2 o'clock Central European Time (Federal Ministry of Justice). It then goes one step further than any interface documentation and gives the two October hours names: the first hour is designated 2A and the second 2B (Federal Ministry of Justice).
European Directive 2000/84/EC fixes the same moment in Universal Time: from 2002 onwards, the summer-time period ends in every member state on the last Sunday in October at 1 a.m. Universal Time (Publications Office of the European Union). For an interface the difference matters more than it looks: expressed in UTC the switch point is one and the same instant for every member state, expressed in local time it sits on three different clock faces in Lisbon, Berlin and Helsinki. Anyone connecting partners across several time zones therefore plans the maintenance stop in UTC and translates it only for the announcement.
Plan the maintenance stop in UTC
Store UTC, display local
The split that holds is an old one: an instant is stored in Coordinated Universal Time, transmitted in UTC and converted into the viewer's zone only for display. The internet standard RFC 3339 argues from the matter itself: because the rules for daylight saving are convoluted and can change through local law at unpredictable times, it recommends Coordinated Universal Time for interoperability across system boundaries (RFC Editor). That is not a matter of style but the assurance that a value still designates the same instant after some other country has changed its rule.
The rule has one exception you have to know, or you will build it wrong: wall times are not instants. A pickup slot at the warehouse at 8 o'clock, a quotation deadline at month end and a delivery day hang on the calendar, not on a second of the UTC axis. Convert such values into UTC and store them as instants, and the next changeover moves them by an hour. They belong in storage as a date, as a time, or as a time with a zone name – and the zone name is part of it, otherwise the second site does not know whose 8 o'clock is meant.
- Instant of an event – order receipt, status change, posting, dispatch notice: store in UTC, transmit with an offset, convert only for display.
- Watermark of a delta query – the timestamp of the last change read: UTC only, with no display formatting and no rounding to whole minutes.
- Window of a scheduled run – start, duration and lock period: fixed in UTC, explained in local time in the interface.
- Delivery and pickup date – a calendar day with a time at the site: store as local time with a zone name, so the changeover leaves it where it is.
- Deadline from an agreement – the end of a quotation or call-off period as agreed with call-offs against blanket orders: with the zone written into the contract, and with a clear rule for the last moment of the day.
- Log line – every line in UTC, so that two systems can be compared at all when something goes wrong; what that looks like in operation is covered in observability for interfaces.
Offset in the field: what a timestamp has to carry
A timestamp without a zone is a number with a missing footnote. The RFC 3339 format – the profile of ISO 8601 dates that, in the words of the standard, should be used in new protocols on the internet (RFC Editor) – writes the offset as a sign with hours and minutes after the time of day. The sign rule is stated there explicitly: numeric offsets are calculated as local time minus UTC (RFC Editor). A value carrying +02:00 is therefore two hours ahead of UTC; converting it back means subtracting.
For changeover night one property follows, and it is the decisive one: two timestamps with the same local time but different offsets designate two different instants – and every system can sort them, compare them and convert them back to UTC. Without the offset what remains is a string with two meanings whose order cannot be reconstructed afterwards. The standard even provides for the case where UTC is known but the offset to local time is not: if the time in UTC is known but the offset to local time is unknown, this can be represented with an offset of -00:00 (RFC Editor). Whoever sees that value in a message knows that a piece of information is missing – at least it is missing visibly.
{
"event_id": "evt-8f2c41",
"event_type": "order.status_changed",
"occurred_at": "2026-10-25T00:30:00Z",
"occurred_at_local": "2026-10-25T02:30:00+02:00",
"local_timezone": "Europe/Berlin",
"tzdata_version": "2026c",
"order": {
"id": "AB-4711",
"status": "released"
},
"delivery_date": "2026-10-27",
"pickup_window": {
"date": "2026-10-27",
"time": "08:00",
"timezone": "Europe/Berlin"
}
}Three things stand out in this event. The leading value is UTC; local time sits beside it as derived information and is recognisable by its offset. The zone name is delivered with it, because it names the rule the conversion followed, and the release of the zone rules stands next to it. The pickup slot, by contrast, remains a calendar day with a time and a zone, because it is an appointment at the warehouse and not a point on the UTC axis.
The zone name does not replace the offset
Europe/Berlin says which rule the conversion follows, but not which of the two October hours is meant. Only the offset separates 2A from 2B. So transmit both: the instant in UTC as the leading value, and the zone name as information about how the display is produced. Transmit only the zone name and leave the conversion to the recipient, and you move the problem into a system whose zone data release you do not know.Delta queries: the error without an error message
Most integrations fetch changes not as an event stream but as a query: give me everything that has changed since instant X. Instant X comes from the last run, the ERP field is called something like changed-at, and as long as both use the same time axis this works. On changeover night it fails in two ways, and both stay silent – no abort, no entry in the error log, only a different data set than expected.
In October local time runs through one hour twice. A run holding its watermark in local time reads hour 2A, remembers 2:59, and in hour 2B reads everything written between 2:00 and 2:59 all over again. In spring the hour is missing: subtract a safety margin of one hour in the application to compensate for clock drift, and you ask for an instant that does not exist on that day, receiving either a silent shift or an abort depending on the library. Records read twice are the milder case, as long as processing is idempotent; records skipped are noticed only when a customer asks about an order.
-- The time axis of the query is UTC, whatever the session time zone is
SET time_zone = '+00:00';
SELECT o.order_no, o.changed_at_utc, o.status
FROM erp_orders o
WHERE o.changed_at_utc > :last_watermark_utc
AND o.changed_at_utc <= :run_started_utc
ORDER BY o.changed_at_utc, o.order_no;
-- The new watermark is the largest change timestamp read,
-- not the application server's clock and not the run's start time.Scheduled runs on the night of the changeover
A schedule written in local time does not know about the doubled hour. A run at 2:30 starts twice in October and is skipped in March. For a sync that runs every quarter of an hour anyway this has no consequences. For a run that transfers stock once a night, creates invoices or sends a file to a partner, it is a duplicated or a missing operation – and both show up first thing on Monday morning.
- Move every schedule to UTC and keep local time only in the description of the plan.
- Avoid runs between 0:00 and 2:00 UTC on changeover night; where they are needed, give them a lock against a second start.
- Give every run an identifier carrying its time window, so that a second start of the same window ends without effect.
- Set the watermark after each run from the largest change timestamp read, not from the server's clock.
- Chain runs with a fixed order instead of spreading them across clock times: the successor starts on the result of its predecessor.
- Write a log for this night that carries UTC and local time side by side, so the sequence can be checked in the morning without mental arithmetic.
Two runs, one window
The time zone database is a dependency
Which offset applies on which date is not written in a formula but in a table. Operating systems, runtimes and databases read that table from the time zone database maintained at the Internet Assigned Numbers Authority. It changes as soon as a country changes its rule – and that happens more often than the quiet in Central Europe suggests. Six releases appeared between January 2025 and July 2026 (IANA).
An example from the current year shows the lead time: release 2026c of 8 July 2026 announces Morocco's move to a permanent offset of +00:00 on 20 September 2026 (IANA). Anyone agreeing dates or deadlines with partners there needs that release in every system involved: in the application server, in the database and in the middleware. A system calculating with an older release delivers a plausible but shifted local time; nothing about it looks like a fault. Which is why the zone data release belongs in the deployment like a program library – and in the test environment before it goes into operation.
| Field | Type and storage | What happens on changeover night |
|---|---|---|
| Order receipt | Instant in UTC | Stays unambiguous, the sequence is preserved |
| Change timestamp in the ERP | Instant in UTC | The delta query reads every change exactly once |
| Change timestamp in local time | Date and time without a zone | One hour is ambiguous, in March one hour is missing |
| Delivery date | Calendar day without a time | Unchanged, because no instant is meant |
| Pickup slot at the warehouse | Time with a zone name | Stays 8 o'clock on site, the offset moves with it |
| Window of a run | Start in UTC with a window identifier | A second start in the same window ends without effect |
What the customer sees on screen
In a customer account it is not storage that counts but explanation. An order status showing 2:30 is ambiguous on changeover night, the same status showing 2:30 CEST is not. The abbreviations CET and CEST do in the display what the offset does in the data format: they name the hour. The same goes for cut-off and pickup times as soon as customers order from more than one country. How an account takes over status values from the ERP without losing the time reference is covered in the article on live order status in the B2B account.
Two displays deserve particular attention, because commitments hang on them. A cut-off for same-day dispatch is a deadline: if it is displayed in local time and checked in UTC, the conversion has to use the same rule as the display – for shipments involving hazardous goods, paperwork and pickup slots hang on it as well. And a countdown running in the browser calculates with the device's zone, not the warehouse's; it shows a customer in another time zone a different remaining time than the server has. Both cases are solved by having the server deliver the end instant in UTC and letting the display translate it.
What applies and what is open
Whether the twice-yearly changeover will remain has been discussed for years. The European Commission ran a public consultation on it in the summer of 2018. Although the consultation period was shorter than the usual period of twelve weeks, around 4.6 million responses were received, 99 per cent of them from citizens (European Commission). 84 per cent of all respondents were in favour of abolishing the twice-yearly clock change, 16 per cent wanted to keep it (European Commission). An open consultation, however, does not question a drawn sample but those who respond of their own accord – the figures describe the participants, not the population.
For practice in an interface a plain consequence follows: what governs is the rule by which the clocks are set today, and that rule stands in the German summer time ordinance and in Directive 2000/84/EC. If a time rule changes, the change reaches systems through a new release of the time zone database and not through a message in the inbox. An integration that keeps instants in UTC and converts in a single place survives that with one update step; an integration that passes local times through five systems needs a project for it. It is the same lever as in resolving data conflicts in bidirectional sync: decide on a leading source and there is less to arbitrate later.
The hour from 2 o'clock to 3 o'clock occurs twice.
The test plan before the last October weekend
The test needs no large landscape, but it does need a date before the night itself. One pass with the system clock moved forward, in a copy of the environment, shows in half an hour what would otherwise become visible on Monday morning. What matters is that the copy uses the same zone data release as production, otherwise you are testing a different rule from the one that will apply. If preparation is on the plan anyway, attach it to the preparation for stocktaking and the year-end – the questions put to the time axis are the same.
- Every time field in the exchanged messages carries an offset or a zone name, and its meaning is written into the interface contract.
- The watermark of every delta query is held in UTC and set from the largest change timestamp read.
- All scheduled runs for the night are timed in UTC and carry a window identifier against a double start.
- The zone data release is the same in application server, database and middleware, and is documented in the deployment.
- A trial run with the system clock moved across changeover night has taken place, the log has been read, duplicated and missing records have been counted.
- Displays tied to a deadline name the time zone, and the server delivers the governing end instant in UTC.
If one finding stays open at the end, the order is clear: delta queries first, then the schedules, then the display. The first two produce data, the third produces queries – and data is harder to repair afterwards than a label. For putting this into an existing integration the routes are the same as for building it: through orderly API development or through ERP and inventory integration, depending on where the time axis breaks today.
Sources and rules
Related Articles
Partial Deliveries and Part Invoices in the B2B Shop
Partial deliveries and part invoices between shop, middleware and ERP: data model, open quantity, document references and the fields of the electronic invoice.
Units of Measure and Pack Sizes from ERP to Your Shop
Separate base, stock, selling and purchase units, pull conversion factors from the ERP, and map stock, minimum quantities and unit prices correctly.
ERP Outage: Keeping the Shop Selling in Fallback Mode
Absorb an ERP outage: last valid stock and prices with an age stamp, buffered orders, conservative checkout rules and an orderly, deduplicated restart.