Issue with WordPress Year Widget for Years Below 1000

[idovecer]

I have noticed that the WordPress year widget does not function correctly when years below 1000 are used. For instance, I have created a history page where historical event dates are entered in WordPress date field. When entering a date with a year below 1000, WordPress displays such dates with leading zeros in admin area.

For example, if I enter the date as 01.01.420 (dd.mm.yyyy), the Year Archive widget leads to /420/, which does not work as expected (4040 Not found). However, if I manually add a leading zero in front /0420/, it displays correctly as /0420/.

How can this issue be resolved?
Thank you.

[ironprogrammer]

Welcome to Trac, @idovecer, and thanks for the report!

I am able to reproduce this issue with Twenty Twenty-One in the default Archives sidebar widget (Figure 1).

I'm also able to reproduce in Twenty Twenty-Three (block theme) by adding the Archive block in the site editor (Figure 2). The following report reflects those results.

Reproduction Report

Steps to Reproduce

1. With a block theme active, add an Archive block to a page template, set it to group by "Year", "Month", or "Day", and save (I used the Single template for expediency).
2. Create or modify a post and set the post date to a year earlier than 1000.
3. 👀 Observe that the editor enforces leading zeros for the year (forcing yyyy format).
4. Save and view/preview the post on the frontend. If permalinks are configured to include the year, 👀 observe that it also includes leading zeros in the URL.
5. 👀 Observe that the Archive block's representation of the year does not include leading zeros.
6. 👀 Observe that navigating to the rendered link results in a 404.

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 13.5.2
• Browser: Safari 16.6
• Server: nginx/1.25.2
• PHP: 7.4.33
• WordPress: 6.4-alpha-56267-src
• Theme: twentytwentythree v1.2

Actual Results

• ✅ The Archive block's generated URL does not include leading zeros, resulting in a 404 when clicked (reproduced).

Supplemental Artifacts

Figure 1:

Figure 2:

Trac ticket: https://core.trac.wordpress.org/ticket/59381

This PR adds leading zeros when year has less than 4 digits.

## Steps to Test

1. With a block theme active, add an Archive block to a page template.
2. Set permalinks to use "Month" based URL structure.
3. Create or modify a post and set the post date to a year earlier than 1000, for example 420.
4. Save and view/preview the post on the frontend.
5. The Archive block's representation of the year should include leading zeros.
6. The /420 archive listing page should work and does not show to a 404.

This is ready for Code Review.

[sumitbagthariya16]

Test Report
---

Testing Environment

• WordPress - 6.4-beta1-56736
• Web Server: Nginx
• Chrome Version - 116
• Firefox - 117
• Theme: Twenty Twenty-Three
• PHP - 7.4.0

Test Result
Works as expected With a block theme and an Archive block in the page template, Please check the below video proof.

Video proof
​https://imgur.com/zCdlHXY.mp4

Tested PR:
​https://github.com/WordPress/wordpress-develop/pull/5330

Thanks for the patch, @faisal-alvi!

I wonder what consensus is on the frontend's _display_ of years < 1000, versus how the slugs are formatted. For instance comparing:

1. September 26, 520
2. September 26, 0520

I prefer the first, without the leading zero. That's the English standard (e.g. ​Wikipedia's date guidelines), but I'm unsure for other languages/cultures. Rather than make a suggestion to change this at this time, I feel that additional contributor input would be valuable.

As for slugs, they're currently forced into YYYY format, so the update to the underlying anchor links in the archive list function how I'd expect.

[JeffPaul]

While the fix here may be good, I wonder if the root issue is actually something of concern for core. How many sites are really going to have a post that references a year published before 1,000?

[karmatosed]

I have to agree with the suggestion here to close. I don't think this is a concern either or something to fix. I am trying to find a use case and if we can we absolutely should reopen this and look at a solution. Until then, closing with wontfix makes sense. Thank you though for the suggestion, remember closing doesn't mean we can't always reconsider.