Fix bump segments iteration order and day of month/week intersection/union handling

[codenem]

Fixes #33

Issue is that sometimes changing a part of the ref date should also change other parts.
Example: If we bump year while computing next tick, we must then put ref to 1st January of next year, at midnight.
To implement this logic the iteration over segments have been reversed to start with segments corresponding to bigger time periods, and the bump function has been updated to handle this new logic of dependent segment changes.

Fixes #26

Issue was that when using steps for months (e.g. 3/*) the fact that months start at 1 (January) and not 0 must be taken into account.

About day of week and day of month

So according to crontab guru (see tip 1 in https://crontab.guru/tips.html) and also general crontab standard, day of week and day of month are intertwined. So if any starts with * the computed day must match the intersection of the two. If not, it must match the union.

[adhocore]

wow, thanks for this 👍. will take a look closely later when im in a PC

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 96.93878% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 93.88%. Comparing base (d3b6afc) to head (d971949).
Report is 2 commits behind head on main.

Files	Patch %	Lines
next.go	95.23%	1 Missing and 2 partials ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #35      +/-   ##
==========================================
- Coverage   94.78%   93.88%   -0.90%     
==========================================
  Files           9        9              
  Lines         594      671      +77     
==========================================
+ Hits          563      630      +67     
- Misses         16       22       +6     
- Partials       15       19       +4     

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

[adhocore]

i have yet to review but wanted to let the actions run thru. it's great that tests/builds passed, only a little comment from coverage bot codecov.

[codenem]

i have yet to review but wanted to let the actions run thru. it's great that tests/builds passed, only a little comment from coverage bot codecov.

Understood thanks! I will add the missing coverage.

[codenem]

@adhocore added new tests for coverage

[adhocore]

i think it is 1 based i.e Sunday = 1

In day-of-week, it specifies the “last day of a week.” It can also be used with another value in , like “6L”, which denotes the “last Friday"

[codenem]

Yes both exists depending what tool you use, e.g. linux crontab uses 0 or 7 for Sunday (man 5 crontab).
Since the gronx code has been using 0 or 7 for Sunday (because it checks with go's time Weekday() method), I fixed the readme accordingly.

[adhocore]

alright then (im also thinking for a feature in yet another release to make configurable for whether to use 0 based or 1 based for ordinal modifiers - but it could be overkill given the gronx is intended to be a lean/minimal lib)

[adhocore]

thank you for clarification. seems now we are near merging this PR. while it is more of personal preference, is there a way to make some var name shorter instead like monthDaySegIsIntersecting