Demo: a meeting across time zones and a daylight-saving change

Written Explanation

The plan

The steps follow the module's idea: think in moments, store UTC, convert at the edge.

1. Create the meeting as 09:00 in Europe/London on a chosen date.
2. Convert it to an Instant (this is what would go into storage) and print it.
3. Print it in London, Riyadh and New York, with each offset.
4. Repeat for several dates around the daylight saving changes.
5. Compute the days until a deadline.
6. Make the mistake on purpose and fix it.

Step 1: the program

import java.time.*;
import java.time.format.DateTimeFormatter;
import java.time.temporal.ChronoUnit;
import java.util.List;
import java.util.Locale;

public class MeetingPlanner {
    private static final DateTimeFormatter OUT =
            DateTimeFormatter.ofPattern("EEE dd MMM yyyy HH:mm (xxx)", Locale.ENGLISH);

    static void show(Instant meeting, List<String> zones) {
        System.out.println("Stored: " + meeting);
        for (String id : zones) {
            System.out.println(String.format("%-17s", id) + meeting.atZone(ZoneId.of(id)).format(OUT));
        }
    }

    public static void main(String[] args) {
        ZoneId london = ZoneId.of("Europe/London");
        List<String> zones = List.of("Europe/London", "Asia/Riyadh", "America/New_York");
        for (LocalDate day : List.of(LocalDate.of(2026, 3, 2), LocalDate.of(2026, 3, 16),
                                     LocalDate.of(2026, 3, 30))) {
            Instant meeting = ZonedDateTime.of(day, LocalTime.of(9, 0), london).toInstant();
            show(meeting, zones);
            System.out.println();
        }
    }
}

Points to notice:

• ZonedDateTime.of(date, time, zone) is another form of of: it takes a LocalDate, a LocalTime and a zone. It builds the meeting as "09:00 on that date, in London".
• .toInstant() removes the zone and keeps the moment. The method show receives only an Instant: it does not know or care where the meeting was planned.
• String.format("%-17s", id) pads the zone name so the columns line up. It is not part of the date API.
• The formatter pattern xxx prints the offset as +01:00 style text, and EEE the abbreviated day name. Both are pattern letters in the DateTimeFormatter Javadoc; the text letters depend on the locale, so the formatter has Locale.ENGLISH.
• The formatter is a private static final constant, as Lesson 4 recommended.

Step 2: the output

Stored: 2026-03-02T09:00:00Z
Europe/London    Mon 02 Mar 2026 09:00 (+00:00)
Asia/Riyadh      Mon 02 Mar 2026 12:00 (+03:00)
America/New_York Mon 02 Mar 2026 04:00 (-05:00)

Stored: 2026-03-16T09:00:00Z
Europe/London    Mon 16 Mar 2026 09:00 (+00:00)
Asia/Riyadh      Mon 16 Mar 2026 12:00 (+03:00)
America/New_York Mon 16 Mar 2026 05:00 (-04:00)

Stored: 2026-03-30T08:00:00Z
Europe/London    Mon 30 Mar 2026 09:00 (+01:00)
Asia/Riyadh      Mon 30 Mar 2026 11:00 (+03:00)
America/New_York Mon 30 Mar 2026 04:00 (-04:00)

Read it like a detective. The meeting is "09:00 in London" on all three days, yet:

• 2 March. Nobody has changed clocks. London is UTC+0, Riyadh +3, New York -5. The meeting is at 09:00 UTC, 12:00 in Riyadh and 04:00 in New York.
• 16 March. New York changed its clocks forward on 8 March (the day that has only 23 hours, as Lesson 1 showed), so its offset is now -04:00 and the meeting is at 05:00 there. London has not changed yet. The stored instant is the same time of day, 09:00 UTC.
• 30 March. London moved forward on 29 March. Now "09:00 in London" is 08:00 UTC, so the stored instant changed. Riyadh, which does not use daylight saving, now sees 11:00. New York still sees 04:00, but only because London's offset moved by the same amount.

The lesson of the table: the gap between two cities is not a constant. London to New York is 5 hours on 2 March, 4 hours on 16 March, and 5 hours again on 30 March. London to Riyadh is 3 hours until London changes, then 2 hours. A program that stores "meeting at 09:00 UTC" and a program that stores "meeting at 09:00 London" disagree after 29 March: decide which one your requirement means. A weekly meeting that must stay at 09:00 London time needs the zone (for example Europe/London) stored beside the rule; a one-off moment needs only the Instant.

The dates 8 and 29 March come from JDK 21's time zone data as printed by this program. Rules differ by country and year, and governments can change them, so check the relevant dates for the year you use rather than trusting these.

Step 3: the deadline

Add this to main:

LocalDate today = LocalDate.of(2026, 3, 1);
LocalDate deadline = LocalDate.of(2026, 4, 15);
System.out.println(ChronoUnit.DAYS.between(today, deadline) + " days, "
        + Period.between(today, deadline));

45 days, P1M14D

Because dates are calendar facts, LocalDate and ChronoUnit.DAYS are the right pair: the deadline is "15 April" wherever the reader lives. In a real application you would replace the fixed today with LocalDate.now() at the edge of your program, and pass it in, so that the calculation stays testable.

Step 4: the planned mistake

Suppose we had represented the meeting as a LocalDateTime, a date and time with no zone:

LocalDateTime m = LocalDateTime.of(2026, 3, 30, 9, 0);
System.out.println(m.withZoneSameInstant(ZoneId.of("Asia/Riyadh")));

The compiler refuses:

Bad.java:4: error: cannot find symbol
 System.out.println(m.withZoneSameInstant(ZoneId.of("Asia/Riyadh")));
                     ^
  symbol:   method withZoneSameInstant(ZoneId)
  location: variable m of type LocalDateTime

There is no withZoneSameInstant on LocalDateTime, because without a zone there is no moment to preserve. This is the compiler doing you a favor: the type system tells you the data is too weak. The fix is to say which zone the meeting was written in:

LocalDateTime naive = LocalDateTime.of(2026, 3, 30, 9, 0);
System.out.println(naive.atZone(london).withZoneSameInstant(ZoneId.of("America/New_York")));

2026-03-30T04:00-04:00[America/New_York]

atZone(london) is the decision "this clock reading was written in London". After it the value is a ZonedDateTime and conversion works.

Be careful: a mistake that compiles is worse. Imagine m.atZone(ZoneId.systemDefault()) instead: it compiles, runs and gives a different answer on a server in a different zone. Always name the zone you mean.