fix: export scalar datetime as a scalar dataset#835
Open
ehennestad wants to merge 3 commits into
Open
Conversation
- A scalar datetime was wrapped in a cell. This is an unnecessary mutation which is removed here - A cell array of datetimes where all values either have TimeZone info or do not, is now output as a datetime array.
Undo non-scalar cell array to datetime array. Mutating outputs should be minimised
Add test ensuring scalar dataset is NOT read as datastub Add test checking that scalar datetime is exported to a scalar dataspace
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #835 +/- ##
=======================================
Coverage 95.31% 95.31%
=======================================
Files 219 219
Lines 7647 7647
=======================================
Hits 7289 7289
Misses 358 358 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
3 tasks
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.
Motivation
Problem
When a scalar
datetimeproperty such assession_start_timeis set,types.util.correctTyperannum2cellon it, converting the scalardatetimeinto a 1×1 cell array before formatting. On export that 1×1 cell was written to HDF5 as a 1-element, non-scalar dataset instead of a scalar dataset.So a value that is conceptually scalar was stored with the wrong dataspace. The exported file no longer reflected the field's scalar shape, the value did not round-trip faithfully (a scalar went in, a 1-element array came back), and on read it was returned as a lazy
DataStubinstead of an eagerly-loaded scalar.Solution
Drop the
num2cellconversion and format datetimes in place, so thedatetimebranch ofcorrectTypepreserves the class and shape of its input:datetimestays a scalardatetimedatetimearray stays adatetimearray (formatted element-wise)Scalar datetime properties are now written as scalar datasets. Covered by a test asserting the scalar dataspace on export, plus an updated reader test reflecting that a scalar dataset is read eagerly rather than as a
DataStub.How to test the behavior?
Checklist
fix #XXwhereXXis the issue number?🤖 Generated with Claude Code