Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interval arithmetic broken for Timestamp(..) types using comparison operators #7756

Closed
mhilton opened this issue Oct 6, 2023 · 1 comment · Fixed by #7758
Closed

Interval arithmetic broken for Timestamp(..) types using comparison operators #7756

mhilton opened this issue Oct 6, 2023 · 1 comment · Fixed by #7758
Labels
bug Something isn't working

Comments

@mhilton
Copy link
Contributor

mhilton commented Oct 6, 2023

Describe the bug

When applying propagate_comparison to Intervals with the type Timestamp(..) produces unexpected results. In the test below the upper value coming from a less-than operation fails to propagate.

This seems to be a result of time arithmetic being special.

To Reproduce

Run the following test:

    #[test]
    fn test_propagate_comparison() {
        let left = Interval::new(
            IntervalBound::make_unbounded(DataType::Int64).unwrap(),
            IntervalBound::make_unbounded(DataType::Int64).unwrap(),
        );
        let right = Interval::new(
            IntervalBound::new(ScalarValue::Int64(Some(1000)), false),
            IntervalBound::new(ScalarValue::Int64(Some(1000)), false),
        );
        assert_eq!(
            (
                Some(Interval::new(
                    IntervalBound::make_unbounded(DataType::Int64).unwrap(),
                    IntervalBound::new(ScalarValue::Int64(Some(1000)), true)
                )),
                Some(Interval::new(
                    IntervalBound::new(ScalarValue::Int64(Some(1000)), false),
                    IntervalBound::new(ScalarValue::Int64(Some(1000)), false)
                )),
            ),
            propagate_comparison(&Operator::Lt, &left, &right).unwrap()
        );

        let left = Interval::new(
            IntervalBound::make_unbounded(DataType::Timestamp(
                TimeUnit::Nanosecond,
                None,
            ))
            .unwrap(),
            IntervalBound::make_unbounded(DataType::Timestamp(
                TimeUnit::Nanosecond,
                None,
            ))
            .unwrap(),
        );
        let right = Interval::new(
            IntervalBound::new(ScalarValue::TimestampNanosecond(Some(1000), None), false),
            IntervalBound::new(ScalarValue::TimestampNanosecond(Some(1000), None), false),
        );
        assert_eq!(
            (
                Some(Interval::new(
                    IntervalBound::make_unbounded(DataType::Timestamp(
                        TimeUnit::Nanosecond,
                        None
                    ))
                    .unwrap(),
                    IntervalBound::new(
                        ScalarValue::TimestampNanosecond(Some(1000), None),
                        true
                    )
                )),
                Some(Interval::new(
                    IntervalBound::new(
                        ScalarValue::TimestampNanosecond(Some(1000), None),
                        false
                    ),
                    IntervalBound::new(
                        ScalarValue::TimestampNanosecond(Some(1000), None),
                        false
                    )
                )),
            ),
            propagate_comparison(&Operator::Lt, &left, &right).unwrap()
        );
    }

Expected behavior

The test should pass, more preciesly the behaviour of a Timestamp(..) type should be similar to that of Int64.

Additional context

No response

@mhilton mhilton added the bug Something isn't working label Oct 6, 2023
@alamb
Copy link
Contributor

alamb commented Oct 6, 2023

cc @berkaysynnada in case you have any insight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants