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

DST handling fixes (fixes #111, #112) #115

Merged
merged 18 commits into from Jan 5, 2022

Conversation

AllenJB
Copy link

@AllenJB AllenJB commented May 31, 2021

Implemented fixes and added related tests for DST change handling (#111 and #112).

Additionally optimized getMultipleRunDates to avoid looping over dates already calculated

I needed to change the function signature on isSatisfiedBy to add the $invert value (direction time is travelling) to get these changes to work correctly.

There is an inconsistency in calculating run dates forwards and backwards over DST changes with some expressions (see
DaylightSavingsTest::testOffsetDecrementsEveryOtherHour ) but I'm not sure there's a (sensible) way to fix this.

If you find any cases these changes break or want me to add some particular tests, please let me know.

AllenJB and others added 18 commits May 22, 2021 21:37
WIP as I believe the change to HoursField::isSatisfiedBy is going to break expressions with multiple parts - but one thing at a time!
API change: isSatisfiedBy now requires knowledge of which direction we're travelling in to handle checking initial values correctly
…egardless of whether they occurred when changing minute or hour (and to persist them until a next change is made)
Use a cache of timezone transitions to avoid having to modify date/time objects every single time we want to check if hour is satisfied
All tests pass
All tests pass
All tests pass
All tests pass
All tests pass
@dragonmantank dragonmantank merged commit 0e9fa24 into dragonmantank:master Jan 5, 2022
@dragonmantank
Copy link
Owner

Thanks!

dragonmantank added a commit that referenced this pull request Jan 5, 2022
* DST fix (attempt 1)

* More tests and further fixes
WIP as I believe the change to HoursField::isSatisfiedBy is going to break expressions with multiple parts - but one thing at a time!

* WIP More tests and further fixes;
API change: isSatisfiedBy now requires knowledge of which direction we're travelling in to handle checking initial values correctly

* WIP Save Point - Trying to fix one thing breaks another, but I have an idea...

* WIP Abstracted NextRunDateTime which keeps track of offset changes, regardless of whether they occurred when changing minute or hour (and to persist them until a next change is made)

* WIP Fix easy fixes

* WIP More test fixes

* All current tests pass!

* Fix for issue #112;
Use a cache of timezone transitions to avoid having to modify date/time objects every single time we want to check if hour is satisfied
All tests pass

* Cleanup
All tests pass

* Cleanup
All tests pass

* Cleanup - backing out the NextRunDateTime abstraction;
All tests pass

* Cleanup;
All tests pass

* Cleanup (diff tidy, restoring deleted tests);
All tests pass

* Cleanup (diff tidy);
All tests pass

* Fix CI issues

* Fix CI issues

Co-authored-by: Chris Tankersley <chris@ctankersley.com>
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.

None yet

2 participants