Lock in 2.x's resilience to the #296 cron date bug - #302
Merged
Merged
Conversation
2.x's PostRepository::get_modified_posts_since() already sidesteps the 1.5.4 cron date-handling bug because the refactor switched to gmdate() and dropped the get_gmt_from_date() round trip. Nothing currently locks that in, though: the existing test runs in UTC and the 2.x TimezoneTest is markTestSkipped pending a wider DDD refactor. Add a negative-offset test (America/New_York) so a future refactor cannot silently reintroduce the local-time round trip. Also clarify in the msm_pre_get_last_modified_posts filter docblock that the $date argument is UTC. The 1.x docblock had the same vague wording and it contributed to the confusion that produced the original bug.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
#296 reported that incremental sitemap updates silently stopped on negative-offset timezones in 1.5.4. The cause was a local-time round trip through
get_gmt_from_date()that re-applied the site offset and pushed the cutoff into the future. PR #297 fixed that ondevelop.While reviewing whether the same fix needed porting to 2.x, I found that the equivalent function —
PostRepository::get_modified_posts_since()— already usesgmdate()directly and skips the local-time round trip. The refactor accidentally fixed the bug. Nothing currently guards against a future refactor reintroducing it, though: the existingtest_get_modified_posts_sinceruns in the default UTC timezone, and the broaderTimezoneTestismarkTestSkipped'd pending its own DDD refactor (with a@todoto that effect).This PR adds a regression guard in
America/New_Yorkso the absence of the bug is a tested property rather than a happy accident.It also clarifies the
msm_pre_get_last_modified_postsfilter docblock to specify that the$dateargument is UTC. The 1.x docblock had the same vague wording and contributed to the confusion that produced the original bug — worth fixing while we're here.No production behaviour changes.
Test plan
test_get_modified_posts_since_finds_posts_in_negative_offset_timezone