Read the distance of times as the interval MEOS answers - #138
Merged
estebanzimanyi merged 1 commit intoOct 3, 2026
Merged
estebanzimanyi merged 1 commit into
estebanzimanyi merged 1 commit into
Conversation
tstzspan.distance answers the seconds, with their fraction, of the interval distance_tstzspan_tstzspan and distance_tstzspanset_tstzspan return, and tstzset.distance the Duration of the interval distance_set_timestamptz and distance_tstzset_tstzset return. ConversionUtils.interval_to_timedelta reads an interval's fields where the catalog lays them out, the microseconds at byte 0, the days at byte 8 and the months at byte 12, and refuses an interval holding months, which has no fixed duration. ConversionUtilsIntervalTest reads one day, a time below a day, a fraction of a second and days with a time, and refuses one month; TsTzSetTest asserts the 120 days between its sets. Witness: MobilityDB 43cfd3f936 (#2942) returns the seven distances between times as an Interval *, where they returned a double, and jmeos-core no longer compiles against it: tstzspan.java and tstzset.java pass the Pointer where a double is read. interval_to_timedelta parsed interval_out with a pattern of "N days HH:MM:SS", so "1 day", "03:04:05" and "00:00:01.25" raised or lost their fraction. Why: JMEOS builds against MobilityDB master, so every JMEOS build fails until it reads the interval MEOS answers. Measured: against MobilityDB 43cfd3f936 and the catalog of MEOS-API 1192ae4f01, the clean build and suite pass, 1,800 and 106 tests, with no warning.
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.
tstzspan.distance answers the seconds, with their fraction, of the interval
distance_tstzspan_tstzspan and distance_tstzspanset_tstzspan return, and tstzset.distance
the Duration of the interval distance_set_timestamptz and distance_tstzset_tstzset return.
ConversionUtils.interval_to_timedelta reads an interval's fields where the catalog lays them
out, the microseconds at byte 0, the days at byte 8 and the months at byte 12, and refuses an
interval holding months, which has no fixed duration. ConversionUtilsIntervalTest reads one
day, a time below a day, a fraction of a second and days with a time, and refuses one month;
TsTzSetTest asserts the 120 days between its sets.
Witness: MobilityDB 43cfd3f936 (#2942) returns the seven distances between times as an
Interval *, where they returned a double, and jmeos-core no longer compiles against it:
tstzspan.java and tstzset.java pass the Pointer where a double is read. interval_to_timedelta
parsed interval_out with a pattern of "N days HH:MM:SS", so "1 day", "03:04:05" and
"00:00:01.25" raised or lost their fraction.
Why: JMEOS builds against MobilityDB master, so every JMEOS build fails until it reads the
interval MEOS answers.
Measured: against MobilityDB 43cfd3f936 and the catalog of MEOS-API 1192ae4f01, the clean
build and suite pass, 1,800 and 106 tests, with no warning.