Opened 4 years ago
Last modified 4 years ago
#52220 accepted defect (bug)
Weekly archives/week 53 incorrect crossing over a year change
Reported by: | sugeneris | Owned by: | Rarst |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.6 |
Component: | Date/Time | Keywords: | needs-patch needs-unit-tests |
Focuses: | Cc: |
Description
I run a site that publishes items every single day, and I regularly make use of its weekly archives.
The relevant dates here(via https://www.epochconverter.com/weeks/2020) are:
2020 week 52 is Dec 21 – Dec 27
2020 week 53 is Dec 28 – Jan 3
2021 week 1 is Jan 4 – Jan 10
Instead, my weekly archives come out as:
2020 week 52 is Dec 21 – Dec 27
2020 week 53 is Dec 28 – Dec 31
2021 week 1 is Jan 4 – [ongoing]
[I can provide live URLs for these, just wasn't sure if self-linking was frowned upon.]
There's three days in there that just…don't exist(in the archives; there are published entries).
It's kind of a pain to find much information on weekly archives in the first place since they're not all that common in actual use and the search terms are broad but I'm currently trying to find someplace else that publishes often enough I can try feeding it a query string to see what happens.
This replicates for previous year changes, ie. 2020 week 1 is Dec 30, 2019–Jan 5, 2020 but the archive just starts at Jan 1 instead.
Also replicates with all plugins disabled and using Twenty Twenty-One.
Change History (10)
#2
@
4 years ago
http://betteridgeslaw.com/2020/?w=52
http://betteridgeslaw.com/2020/?w=53
http://betteridgeslaw.com/2021/?w=1
I don't see how it'd be a factor but since it's custom, those are via an add_rewrite_rule('^week/([0-9]+)/([0-9]+)/?','index.php?m=$matches[1]&w=$matches[2]','top');
As far as whether this is a change in behavior, I only started using the weeklies in 2020 and this is the only place I've seen a discrepancy so couldn't say, unfortunately. My comment about it working for past year changes is just from trying to confirm the behavior this time around.
#4
@
4 years ago
Monday. Changed it to match the Epoch Converter site so I could compare against its listings.
#5
@
4 years ago
Examples you are providing are ISO week numbers. In a nutshell WP seems to neither support ISO weeks or querying by week and year.
Here is what happening with the year=2020,w=53.
You could easily think this queries posts that are in week 53 of year 2020. It does not.
This queries posts that are in year 2020 AND week 53.
2021-01-01 is not in year 2020 so it is not selected by this query.
Also for weeks starting on Monday WP uses MySQL week mode 1 which puts 2021-01-01 into week 2021-0 (instead of mode 3 ISO week 2020-53) and WP doesn't seem to be able to query week 0 at all.
So my current understanding is:
- If you try this query combination there are indeed some "lost" days at the end of the year
- However WP_Query is literally correct giving you combination requested
- There seems to be no way to query week of a specific year
- There seems to be no way to query week 0
- There seems to be no way to query by ISO week number
So as of right now, it seems you would need to figure out custom SQL for it, WP_Query just doesn't know how to do this.
#6
@
4 years ago
From quick search this seems to have been worked on in #10397 and ISO week issue was raised, but not accounted for (given that WP supports arbitrary first day of the week, which would be incompatible with ISO for settings other than monday).
This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.
4 years ago
#8
@
4 years ago
Since this attempts to be consistent with wp_get_archives()
I went to look what happens there and it's more of the same mess. If you request weekly archives you get last week output twice:
- December 28, 2020–January 3, 2021 pointing to
/?m=2021&w=0
(which is broken and just queries 2021 without week limit) - December 28, 2020–January 3, 2021 pointing to
/?m=2020&w=53
(which works but "loses" days, as above)
#9
@
4 years ago
And here I'd thought this might've been along the lines of a relatively simple offset problem or something. All makes sense, though, and there's obviously not a potential solution coming anytime soon. It'd be nice if there were an eventual fix but at least it's just a once-a-year problem for an uncommon archive type. Thanks for digging.
#10
@
4 years ago
- Keywords needs-patch needs-unit-tests added
- Owner set to Rarst
- Status changed from new to accepted
Oh no, not in Date/Time component it's not. :) I am not sure what proper fix would even look like here.
Going by fixing one thing at a time... Not being able to query week 0 should be fixed first, since that argument is in actual use. Then splitting archive generation into partial weeks (week 53 exclusive next year days and those week 0 leftovers) maybe? It's already trying to query partial weeks, so if it works and labels are corrected that would be somewhat logical.
Links please, that will help for a quick look. :)
I think there are several different conventions for what constitutes a numbered week, so I am not right away sure what is intended with those.
To be clear was the behavior different before and you are reporting it has changed? Or just reporting this as something that needs a look?