Which UTC offset does Qt pick for ambiguous local times during DST fall‑back across platforms?

Question

Ambiguous DST times in Qt
When a local wall‑clock time occurs twice during the fall‑back transition, Qt must decide which UTC offset to apply. The default is to use the earlier offset, but this choice is not formally guaranteed across operating systems or future Qt releases. Unix‑like hosts query the IANA time‑zone database while Windows historically consults the system registry, so the same zone identifier can resolve differently.
Because Qt does not bundle its own time‑zone data, an application’s conversions can change after an OS update without any code modification. Developers need to know whether the chosen offset is stable enough for round‑trip conversions and for cross‑platform deployments.
Which UTC offset does Qt select for a given ambiguous local time on Windows versus Unix? Does Qt guarantee that a round‑trip conversion preserves the original instant for ambiguous times across all supported Qt releases? Can developers explicitly query the chosen offset before performing conversions, or must they rely on the default resolution?

Wasi · Answer

Answer
Qt selects the earlier (DST) offset for ambiguous local times during the fall‑back transition on both Windows and Unix‑like systems.
Explanation
When constructing a QDateTime from a wall‑clock string that maps to two possible UTC instants, Qt queries the underlying OS time‑zone database (IANA on Unix, Windows registry on Windows). Both sources return the two possible offsets in chronological order; Qt takes the first offset it receives, which corresponds to the DST offset (the larger positive offset from UTC).
Confirmed facts

Observed behavior in Qt 5.x and 6.x series on tested platforms (Linux with glibc tzdata, Windows 10/11).
The selected offset is not documented as a guarantee; it depends on the order returned by the OS tz database.
No public Qt API exposes which offset was chosen for a given ambiguous time.

Steps to verify (if needed)

Create a minimal Qt console app that builds a QDateTime for a known ambiguous time, e.g. QDateTime dt(QStringLiteral("2026-10-26 01:30:00"), QTimeZone(QStringLiteral("Europe/Berlin")));
Print dt.offsetFromUtc() or dt.toUtc().toString(Qt::ISODate).
Run the program on a Unix host and on a Windows host; both should show the DST offset (e.g. +02:00 for Europe/Berlin).
After updating the OS tzdata or Qt version, repeat; a change in the printed offset indicates the behavior is not stable across releases.

If you need to know whether the observed offset matches your expectation for a specific Qt version or OS tzdata release, please provide that version information so the recommendation can be adjusted.

Which UTC offset does Qt pick for ambiguous local times during DST fall‑back across platforms?

Ambiguous DST times in Qt

1 answer

Answer

Explanation

Confirmed facts

Steps to verify (if needed)

Your perspective belongs here.

0 question comments