Skip to content

coreutils test_date::test_negative_offset and test_date::test_relative_weekdays fail after parse_datetime update #151

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.

Sign up for GitHub

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

Jump to bottom
Open
drinkcat opened this issue May 29, 2025 · 4 comments · May be fixed by #152
Open

coreutils test_date::test_negative_offset and test_date::test_relative_weekdays fail after parse_datetime update #151

drinkcat opened this issue May 29, 2025 · 4 comments · May be fixed by #152

Comments

@drinkcat
Copy link
Contributor 

---- test_date::test_relative_weekdays stdout ----
bin: "/home/drinkcat/dev/coreutils/coreutils/target/debug/coreutils"
run: /home/drinkcat/dev/coreutils/coreutils/target/debug/coreutils date -d last thu --rfc-3339=seconds --utc

thread 'test_date::test_relative_weekdays' panicked at tests/by-util/test_date.rs:472:18:
Predicate for stdout as `str` evaluated to false.
stdout='2025-05-29 00:00:00+00:00
'
stderr=''

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- test_date::test_negative_offset stdout ----
bin: "/home/drinkcat/dev/coreutils/coreutils/target/debug/coreutils"
run: /home/drinkcat/dev/coreutils/coreutils/target/debug/coreutils date -d -1 hour --rfc-3339=seconds

thread 'test_date::test_negative_offset' panicked at tests/by-util/test_date.rs:445:14:
Predicate for stdout as `str` evaluated to false.
stdout='2025-05-28 23:00:00+00:00
'
stderr=''



failures:
    test_date::test_negative_offset
    test_date::test_relative_weekdays
@drinkcat drinkcat changed the title test_date::test_negative_offset and test_date::test_relative_weekdays fail after parse_datetime update coreutils test_date::test_negative_offset and test_date::test_relative_weekdays fail after parse_datetime update May 29, 2025
@sylvestre
Copy link
Contributor

captain obvious: we should replicate these tests in parse_datetime (if possible)

@drinkcat
Copy link
Contributor Author

drinkcat commented May 29, 2025 •
edited
Loading

Bisection:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
07d4b80ea53747ee629a2104a9a41bea16fcbf4e
4c3d2221da1be8f6e091c3842d6ef98983f37527
We cannot bisect more!

I suspect this might be it:

commit 4c3d2221da1be8f6e091c3842d6ef98983f37527
Author: Daniel Hilst <[email protected]>
Date:   Thu Aug 29 14:21:15 2024 -0300

    Restore the old API and add the missing combinators

@yuankunzhang this was merged as part of #137.

I was digging through the code, and what I do not understand is this:

fn at_date_inner(date: Vec<Item>, mut d: DateTime<FixedOffset>) -> Option<DateTime<FixedOffset>> {
    d = d.with_hour(0).unwrap();
    d = d.with_minute(0).unwrap();
    d = d.with_second(0).unwrap();
    d = d.with_nanosecond(0).unwrap();

Why are we resetting the time to midnight? (removing this would fix this test... but... break others)

@drinkcat
Copy link
Contributor Author

captain obvious: we should replicate these tests in parse_datetime (if possible)

Oh yeah absolutely... This kind of cross-repo/crate issue is such a pain...

@drinkcat drinkcat mentioned this issue May 29, 2025
Open
1 task
@yuankunzhang yuankunzhang linked a pull request May 29, 2025 that will close this issue
Open
@yuankunzhang
Copy link
Contributor

Addressed in #152.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix relative date time handling yuankunzhang/parse_datetime
3 participants
@sylvestre @drinkcat @yuankunzhang