Read zoned datetimes as ZonedDateTime, through a TimeZones.jl extension - #255
Open
Thenewmanator15 wants to merge 2 commits into
Open
Thenewmanator15 wants to merge 2 commits into
Thenewmanator15 wants to merge 2 commits into
Conversation
A timetable was returned as a MatlabOpaque, its parts decoded but not assembled.
It now becomes a table (MatlabTable by default, or the `table` type) whose first
column holds the row times, named after the row dimension ("Time" unless renamed),
followed by the variables.
Row times are stored one per row (datetime or duration, already converted to
DateTime or Millisecond), or, for a regular timetable, as a start time and a sample
rate or time step; those are generated. A timetable stepped in calendar units has
no fixed rate and is left as the MatlabOpaque, with a warning. `table=Nothing`
keeps the raw object, as for tables.
test/timetable_gen.m writes test/v7 and test/v7.3/timetable.mat: datetime and
duration row times, sample rate, time step from a datetime start, an empty
timetable, a two-column variable, a renamed row dimension, calendar months. The
.mat files are not included; the timetable tests are skipped until they are
generated in MATLAB and committed.
MATLAB stores a datetime with a time zone as its UTC instant plus the zone's name. The zone was dropped with a warning, leaving the UTC instant as a DateTime. With TimeZones.jl loaded (Julia 1.9+, package extension MATTimeZonesExt), it is now a ZonedDateTime in its zone: an IANA name, "UTC", or a fixed offset such as "+05:30". Without TimeZones.jl, and on older Julia, the result is unchanged (the UTC instant), with a warning that says so and names the package. A zone TimeZones.jl does not recognise falls back to the UTC instant, with a warning. "UTCLeapSeconds" counts leap seconds, which neither DateTime nor ZonedDateTime can represent; it was returned as a DateTime 26 s off (2016-12-31T23:59:60 read as 2017-01-01T00:00:26) and is now left as the MatlabOpaque, with a warning. A regular timetable with a zoned start now works too (the start may be any Dates.AbstractDateTime). test/timezone_gen.m writes test/v7 and test/v7.3/timezone.mat (Europe/London in summer and winter, UTC, +05:30, America/New_York across DST, UTCLeapSeconds, a timetable with zoned row times and a regular one with a zoned start). read.jl checks the file before TimeZones.jl is loaded, the new test/timezones.jl (run last) after. The .mat files are not included; both testsets skip until they are generated in MATLAB and committed. TimeZones.jl is a weak dependency and a test dependency.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #253 (its commit is included here; the new commit is "Read zoned datetimes as ZonedDateTime…").
MATLAB stores a
datetimethat has a time zone as its UTC instant plus the zone's name. MAT.jl drops the zone with a warning (no timezone conversion yet … ignored), leaving the UTC instant as aDateTime. This reads it as aZonedDateTimein its own zone when TimeZones.jl is loaded, through a package extension, so MAT.jl gains no required dependency:Europe/London,America/New_York, across daylight saving),UTC, and fixed offsets such as+05:30—TimeZone()parses all three forms MATLAB writes;DateTime— with a warning that says so and names the package;UTCLeapSecondscounts leap seconds, which neither type can represent: it was returned as aDateTime26 s off (2016-12-31T23:59:60read as2017-01-01T00:00:26) and is now left as theMatlabOpaque, with a warning;Dates.AbstractDateTime).I checked the storage against MATLAB R2025a in both formats: for every zone above the stored value is the UTC instant (e.g. 12:00 BST is stored as 11:00 UTC; 12:00
+05:30as 06:30), and an unzoneddatetimestores its wall-clock time.Tests, and the same request as #253.
test/timezone_gen.mwritestest/v7/timezone.matandtest/v7.3/timezone.mat.read.jlchecks the file before TimeZones.jl is loaded (UTC instants); the newtest/timezones.jl, run last inruntests.jl, loads TimeZones.jl and checksZonedDateTimes (Julia 1.9+). I can't contribute the.matfiles, so they are not included — could someone with MATLAB run the script and commit its two files? Until then these testsets skip. Against the files the script writes: the full suite passes (685) on Julia 1.13 and on 1.9; without them, 581 pass, 6 skipped. TimeZones.jl is a weak dependency and a test dependency (compat"1"; 1.22 supports Julia 1.6).A
NaTin a zoned array is handled by #254; the extension mapsmissingthrough.🤖 Generated with Claude Code