Allow timespan to be specified with common time units

[KenKundert]

#8624

[KenKundert]

This version supports Y/m/d and H/M/S as you specified. Please let me know if you want to support weeks as well. Also, let me know you want make all units other than m and M case insensitive.

[jdchristensen]

I think we should match how borg prune --keep-within works, which allows weeks. It's probably case sensitive, but someone could check the code. If we support minutes and seconds here, we should probably do the same with --keep-within as well.

The --keep-within option takes an argument of the form “<int><char>”, where char is “H”, “d”, “w”, “m”, “y”. For example, --keep-within 2d means to keep all archives that were created within the past 48 hours. “1m” is taken to mean “31d”. 

[ThomasWaldmann]

Yeah, what @jdchristensen says. Consistency within borg is of course more important than consistency to strftime formats (which most users are not aware of anyway).

So, ymwd lowercase, HMS uppercase.

[ThomasWaldmann]

consistency feedback. thanks for the PR!

[codecov]

Codecov Report

Attention: Patch coverage is 96.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 81.83%. Comparing base (1559a1e) to head (ea65cae).
Report is 11 commits behind head on master.

Files with missing lines	Patch %	Lines
src/borg/helpers/time.py	92.30%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8626      +/-   ##
==========================================
- Coverage   81.83%   81.83%   -0.01%     
==========================================
  Files          74       74              
  Lines       13319    13340      +21     
  Branches     1963     1969       +6     
==========================================
+ Hits        10900    10917      +17     
- Misses       1755     1758       +3     
- Partials      664      665       +1     

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

[ThomasWaldmann]

BTW, I just saw that you are working in your local master branch. This can often be a problem (e.g. if you need to rebase onto current upstream master for some reason), so try to remember to always checkout a feature/fix branch first (like git checkout -b myfeature).

It looks like we can quickly merge this PR, so no need to change branches here.

[KenKundert]

I have enhanced 'prune --keep-within' to support seconds and minutes and checked in the changes. I believe I have also made all requested changes.

I cannot run tests locally, there seems to be some issue with the version, the tests all end in a failure complaining about an invalid version number when I run tests locally. So I am just waiting for you to approve the workflows so I can see how many mistakes I made.

Thanks for the suggestion to create and operate on a feature branch. I have limited experience contributing to projects that are not my own.

[ThomasWaldmann]

@KenKundert Likely you did not fetch the tags. setuptools_scm creates the version number based on git tags.

[ThomasWaldmann]

Some minor stuff I found.

[ThomasWaldmann]

found a typo

[KenKundert]

I finally was able to fetch the tags and the tests now are working locally. So going forward there should be many fewer of my stupid mistakes to review. I apologize for the churn.

I think I am basically done, though I will add in support for quarters if you wish.

[ThomasWaldmann]

LGTM!