Skip to content

Conversation

yuankunzhang
Copy link
Contributor

Closes #151.

Copy link
Contributor

@drinkcat drinkcat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, as you noted in your TODO, this is not too pretty ,-)

I wonder, can you do multiple passes over the vector? And remember whether date/time was set? (and recover the missing pieces from at as needed)

It doesn't seem like order matters for the Relative times, e.g.

date "+1 hour 2023-03-03"
date "2023-03-03 +1 hour"

both output

Fri Mar  3 01:00:00 AM CET 2023

I'm not too sure about this codebase, but maybe something like this:

  • Date, DateTime, Time, Year?
  • Then recover date/time from at as required?
  • Then Weekday?
  • Then Relative?

You could use Vec's filter to make sure that we actually go through all items.

(btw, can you cherry-pick just 6ebdf73 for this PR? I don't think this needs to stack on top of the other PR -- but IMHO that other PR could go in first...)

@yuankunzhang yuankunzhang force-pushed the fix-relative-date-time-handling branch from 6ebdf73 to ca7fa0d Compare May 30, 2025 12:40
@yuankunzhang
Copy link
Contributor Author

Okay I've cherry picked only this one commit in the PR.

As for the date time assembling, I've have some ideas how to improve. Will follow up on it.

@drinkcat
Copy link
Contributor

drinkcat commented Jun 1, 2025

Okay I've cherry picked only this one commit in the PR.

Cool thanks.

As for the date time assembling, I've have some ideas how to improve. Will follow up on it.

Do you mean follow-up as a separate PR or here? I'll let maintainers decide, but since we'd need a new release of parse_datetime I'm not sure if it's worth it to submit the current version (as a temporary but working version), make a release, then do some cleanup of this, or if we want to do the cleanup before making a new release.

@yuankunzhang
Copy link
Contributor Author

I will do it in a separate PR.

@sylvestre
Copy link
Contributor

it has a conflict, sorry

@yuankunzhang yuankunzhang force-pushed the fix-relative-date-time-handling branch from ca7fa0d to f4367e4 Compare June 4, 2025 08:52
@yuankunzhang
Copy link
Contributor Author

it has a conflict, sorry

Addressed, thanks.

@cakebaker cakebaker force-pushed the fix-relative-date-time-handling branch from f4367e4 to de9de05 Compare June 14, 2025 13:23
@yuankunzhang yuankunzhang force-pushed the fix-relative-date-time-handling branch 2 times, most recently from 0629d8c to e5af24e Compare June 15, 2025 04:25
@yuankunzhang
Copy link
Contributor Author

Rebased on top of #155 .

@yuankunzhang yuankunzhang force-pushed the fix-relative-date-time-handling branch from e5af24e to 9b67307 Compare June 15, 2025 13:13
@cakebaker cakebaker merged commit 9b67307 into uutils:main Jun 15, 2025
17 checks passed
Copy link

codecov bot commented Jun 15, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 0.00%. Comparing base (c05b821) to head (9b67307).
Report is 4 commits behind head on main.

Additional details and impacted files
@@     Coverage Diff     @@
##   main   #152   +/-   ##
===========================
===========================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

4 participants