Time zones and daylight saving time in client itineraries

Short answer: write every time in the local time of the place where it happens, with the date, the city or zone and “+1” when a flight lands the next day. Check whether any day of the trip falls on a clock change: that day has 23 or 25 hours, one local hour is skipped or repeated, and the time difference with home can change mid-trip.

Most time mistakes in itineraries are not typos. They come from working out a time instead of copying it, from a booking that falls in the hour the clocks skip, or from a time difference that was right last month. This guide shows how to write flight and transfer times so nobody misreads them, which clock changes fall in 2026 and 2027, and how to handle the hours that do not exist or happen twice, with worked examples.

Which time should an itinerary show?

The local time where the thing happens. Airline schedules work this way: an aviation data provider, ch-aviation, sums up the convention as departure and arrival times in the local time of each airport, on the 24-hour clock, with “+1” or “+2” when the flight arrives one or two days after it leaves. Your itinerary should match the ticket the client holds, so a flight from New York to Rome shows its departure in New York time and its arrival in Rome time.

The same goes for everything else: a transfer, a tour or a check-in shows the time of the city it happens in. The client’s home time is useful once per destination, for calls home, not next to every booking.

If you sell packages in the EU, this is also part of the job: Article 7(5) of the Package Travel Directive asks the organiser to give travelers, in good time before the start, the scheduled times of departure, check-in deadlines and the scheduled times for intermediate stops, transport connections and arrival.

How should you write a time so nobody misreads it?

Give the date, the 24-hour time and the place whose clock it is. Name the city, not an abbreviation, and add the UTC offset when the trip crosses zones or a clock change.

Two habits prevent most errors:

• Copy arrival times from the ticket, never calculate them. The ticket already gives the arrival in local time. Adding the flight duration to the departure time and then a time difference is how an hour goes missing.
• Separate the meeting time from the start time. A driver who meets the client at 07:15 for a 07:30 departure is two times, and the client needs the first one.

When do the clocks change in 2026 and 2027?

The EU’s rule is in Directive 2000/84/EC: summer time begins at 01:00 GMT on the last Sunday in March and ends at 01:00 GMT on the last Sunday in October, in every Member State at the same moment. In the US, NIST gives 02:00 local time on the second Sunday of March and the first Sunday of November.

The UK dates are GOV.UK’s; the local times for Rome, Madrid and Athens follow from the 01:00 GMT rule. The NSW dates come from the NSW Government; in the southern hemisphere, summer time runs from spring to autumn there, so October to April.

Not everyone changes. NIST lists Hawaii, most of Arizona (but not the Navajo Nation), American Samoa, Guam, Puerto Rico and the US Virgin Islands as not observing daylight saving time, and the NSW Government lists Queensland, Western Australia and the Northern Territory. The EU’s own end to clock changes is still pending: the Commission proposed it in 2018, and its summertime page says the Council has not finalised its position.

The 23-hour and 25-hour day

On the day the clocks go forward, the local day has 23 hours; on the day they go back, 25. NIST puts it as “one less hour” and “an extra hour” in that day. Anything counted in hours across that night moves on the clock.

Worked example (23 hours). A client picks up a rental car in Naples at 10:00 on Saturday 28 March 2026 for 24 hours. Twenty-four hours later the clock in Italy reads 11:00 on Sunday, not 10:00, because the night lost an hour. If the contract says “return by 10:00 Sunday”, the client has 23 hours.

Worked example (25 hours). The same 24-hour rental from 10:00 on Saturday 24 October 2026 ends at 09:00 on Sunday by the clock. An overnight bus or flight that night takes one hour longer than the clock times suggest.

Non-existent times: the hour the clock skips

When the clocks go forward, one local hour never happens. In Rome, Madrid, Paris or Berlin on 29 March 2026, the clocks jump from 02:00 to 03:00, so 02:30 does not exist. In New York on 8 March 2026, the skipped hour is 02:00 to 02:59.

Worked example. A late arrival in Naples on Saturday 28 March 2026 is delayed, and the agent rebooks the transfer to Positano for “02:30”. That time does not exist that night: a booking system may refuse it or quietly turn it into 03:30, and the client may expect the car an hour before the driver does. Book 01:45 or 03:00 instead, and say “Rome time, after the clocks go forward” in the note.

The same check applies to night trains, early ferries and any booking that crosses that night: look for times between 02:00 and 02:59 local time in the EU zones one hour ahead of UTC, and between 01:00 and 01:59 in London or Lisbon.

Ambiguous times: the hour that happens twice

When the clocks go back, one local hour happens twice. In Rome on 25 October 2026, 02:00 to 02:59 runs first in summer time (UTC+2) and then again in winter time (UTC+1). In New York on 1 November 2026, the repeated hour is 01:00 to 01:59, as NIST describes it.

Worked example. A 02:30 pick-up at a hotel in Rome on Sunday 25 October 2026 could mean two moments one hour apart. Agree with the supplier which one they mean, and write it: “02:30 summer time (UTC+2), the first 02:30”. Better still, move the pick-up out of that hour.

Worked example: when the gap between Europe and the US is five hours

Europe and the US change their clocks on different Sundays, so for a few weeks a year the usual six-hour gap between New York and Rome (or Madrid, Paris, Berlin) is five hours.

In 2027 the five-hour weeks are 14 to 27 March and 31 October to 6 November.

Worked example. A flight leaves New York at 22:00 on Saturday 24 October 2026 and takes 7 hours 30 minutes. It lands in Rome at 10:30 on Sunday, Rome time. An agent who adds 7 h 30 min and the usual six hours writes 11:30, and the client waits an hour at the airport for the driver. The fix is the habit above: copy the arrival time from the ticket. The free arrival time calculator works out the local landing time from the date, so it accounts for clock changes.

Worked example: a trip from Europe to Sydney in October

In the southern hemisphere the clocks move in the opposite season, so the gap between Europe and Australia changes twice within a few weeks.

A client who leaves Rome on 20 October 2026 for three weeks in Australia starts the trip with a nine-hour gap and comes home after it has become ten. If your itinerary says “Sydney is 9 hours ahead of home”, it will be wrong for most of the stay. Write the gap with its dates, or leave it out.

Zone rules change, sometimes with little notice

Time zones are set by governments, and they change. The IANA Time Zone Database, which phones, computers and booking systems use to turn rules into local times, is updated when they do; its latest release on 15 October 2026 was 2026e, of 29 September 2026. Its release notes for 2026 record:

• British Columbia: permanent UTC−7, a change that legally took place on 9 March 2026.
• Alberta: permanent UTC−6 from 18 June 2026.
• Northwest Territories: permanent UTC−6 from 21 August 2026.
• Morocco: permanent UTC+0 from 20 September 2026.
• Manitoba: permanent UTC−5 from 31 October 2026.

So the provinces of British Columbia, Alberta, the Northwest Territories and Manitoba will not turn their clocks back on 1 November 2026, unlike most of the United States. A phone or calendar with outdated zone data can show those places an hour off. For trips there, trust the local time on the ticket and check the destination’s current rule before you send the itinerary.

When a rule change moves a time in a trip you have already sent, treat it like any other change: how to send a changed itinerary to clients.

How Viaondo handles time zones

We make Viaondo, and this is what its code does. Each booking stores the time zone of its start and of its end (an IANA zone such as Europe/Rome), and each hotel stores its own. A time that does not exist in that zone is rejected with a message saying the clocks go forward that night, and a time that happens twice is read as its first occurrence. The offsets come from the server’s zone data and travel with each published trip, so a phone with older zone data still shows the time on the ticket. The traveler app shows each time in local time with the zone’s name, and calendar exports carry times in UTC with the local time and zone in the description. The itinerary builder page shows how bookings are entered.

Checklist for times in every itinerary

1. Write each time in the local time of the place where it happens, with the date and the city or zone.
2. Copy arrival times from the ticket, with “+1” or “+2” where it applies; never work them out from the duration.
3. Check each date of the trip against the clock changes of every zone it touches, at home and at the destination.
4. On a spring-change night, move any booking between the skipped hour’s start and end; on an autumn-change night, agree with the supplier which of the two moments they mean, or move it.
5. Recount anything priced or limited in hours (car rentals, parking, luggage storage) that runs across a clock change.
6. Do not write a fixed time difference with home for a trip that spans a clock change; give it with dates, or leave it out.
7. For destinations that changed their rules recently, check the current rule before you send the trip.
8. Separate the meeting time from the start time, and leave a margin after arrival; on a first trip to the Schengen area, border registration can add time, as our guide to the EU Entry/Exit System explains.

How this guide was checked. The rules and dates come from Directive 2000/84/EC, the European Commission, GOV.UK, NIST, the NSW Government and the IANA time zone database, all opened on 15 October 2026; the worked examples apply those rules to hypothetical bookings, and every UTC offset in the tables was checked against the IANA data. What Viaondo does is described from its own code. This is practical guidance, not legal advice.

To see how other tools handle trips and the apps they send, read our guide to itinerary software for travel agencies.