MATLAB datetime fall-back ambiguity defaults to first occurrence

Question

Goal
Determine how MATLAB's datetime class resolves ambiguous local times during fall-back DST transitions and how the version of the bundled IANA time zone database affects this behavior across different releases.

Constraints and Uncertainty
Since R2020b, the AmbiguousTime parameter allows selecting 'first', 'last', or 'error', but the default behavior silently resolves to the first occurrence (standard time) without a warning. Because MATLAB bundles the IANA database with each release, which lags behind official updates, recent DST law changes (such as those recently implemented in Mexico or Greenland) may not be reflected in older versions. There is no documented mechanism to update this database without an upgrade, and timezones does not expose the database vintage.

Questions

What is the precise default AmbiguousTime value for all releases since R2020b, and is it guaranteed to remain consistent in future versions?
  How can a script reliably identify the specific IANA tzdb version currently bundled in MATLAB without using undocumented internal Java properties?
  If code must produce identical timestamps across different MATLAB releases with varying tzdb versions, what strategy ensures consistency during the repeated hour?

Tasadduq Burney · Answer

MATLAB datetime ambiguous-time default and tzdb version

Since R2020b, the default AmbiguousTime value for constructing a datetime from an ambiguous local time is 'first'. This selects standard time (the first occurrence) without issuing a warning. MathWorks has not provided a guarantee that this default will remain unchanged in future releases; a future tzdb update or a deliberate change to the default could alter behavior.

Default value: 'first' for all releases from R2020b onward; not version-locked.
Identifying bundled tzdb version: The public timezones function does not expose the IANA database vintage. The only known method is locating the file tzdata.jar under the MATLAB root toolbox path (matlabroot/toolbox/shared/timeseries/) and reading its MANIFEST.MF Implementation-Version entry. This relies on undocumented internal directory structure.
Ensuring consistency across releases: Always explicitly specify the AmbiguousTime name-value pair when constructing datetime values in repeated hours (e.g., datetime('2026-10-31T01:30:00', 'TimeZone','America/Chicago', 'AmbiguousTime','first')). If you must run code on multiple MATLAB releases, validate the output after each upgrade or lock the tzdb version via the bundled JAR's java.time.ZoneRules class.

Verification: Construct a datetime in a known ambiguous window and examine its AmbiguousTime property; the default resolution will be 'first'. To check the tzdb version, open tzdata.jar and inspect the manifest's Implementation-Version field.

Do you have access to the MATLAB root directory to locate tzdata.jar, or would you prefer a strategy that avoids internal file paths?

MATLAB datetime fall-back ambiguity defaults to first occurrence

Goal

Constraints and Uncertainty

Questions

1 answer

MATLAB datetime ambiguous-time default and tzdb version

Your perspective belongs here.

0 question comments