Fix datetime encoding precision loss regression for units requiring floating point values #8272
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.
This PR proposes a fix to #8271. I think the basic issue is that the only time we need to update the
needed_units
is if thedata_delta
does not evenly divide theref_delta
. If it does evenly divide it--as it does in the example in #8271--and we try to update theneeded_units
solely according to the value of theref_delta
, we run the risk of resetting them to something that would be coarser than the data requires. If it does not evenly divide it, we are safe to reset theneeded_units
because they will be guaranteed to be finer-grained than the data requires.I modified
test_roundtrip_float_times
to reflect the example given by @larsbuntemeyer in #8271. @kmuehlbauer let me know if this fix makes sense to you.days since
#8271whats-new.rst