Clearer date error messages

[tomyems]

The error 'Date must be a real date' does not help users to fix the problem, as it is not very descriptive. This breaks down the reasons why a date might not be a real date to help users fix the problem and continue with the service.

[netlify]

✅ You can preview this change here:

Built without sensitive environment variables

Name	Link
🔨 Latest commit	c792b80
🔍 Latest deploy log	https://app.netlify.com/sites/govuk-design-system-preview/deploys/66a36e91f5cfa90008c28116
😎 Deploy Preview	https://deploy-preview-3956--govuk-design-system-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tomyems]

Added some decision help suggestions: alphagov/govuk-design-system-backlog#42 (comment)

[querkmachine]

Hi @tomyems, thanks for this contribution.

Edit: To be clear, this is specifically about the "If the date as a whole does not exist" section.

Speaking personally, the error messaging is somewhat ambiguous because the error the user has made is itself often ambiguous and cannot be programatically determined.

For example:

• If I enter 31 06 2024, that is an invalid date, but you don't know whether I've typo'd the day of the month (I could have meant to type 30) or if the day is correct and it's actually the month that's entered incorrectly (it could be 05 or 07).
• If I enter 29 02 2025, that is an invalid date, but you don't know whether I've entered the day wrong (could be 28), the month wrong (could be 01 or 03) or the year wrong (could have meant 2024).

In both examples above, one or more fields could have been entered incorrectly, but it's not possible to determine with any certainty which field or fields are wrong. For this reason it is generally expected that teams validate the date as a whole (as though it came from a single input) rather than validating each of the fields individually.

This doesn't apply if someone has left a field blank or entered the 42nd day of the 13th month, of course—in those cases it's obvious—but hopefully you see what I'm getting at.

[tomyems]

Yes that section is the hardest to get to work - and for transparency I do not have research to support this.

For 31 06 2024, I believe 'Day must be a number between 1 and 30 for June' to be much more helpful that 'Date must be a real date'.

This is because it provides the context to the user about what is wrong with the date - both that 'June' could be wrong or the '31' could be wrong (though it is biased towards 'day'). This is particularly helpful for users who are less familiar with the numerals for dates (perhaps used to different calendar systems and so on). This is why both the 'day' and 'month' field should be highlighted.

You could try '31 June does not exist. For June, day must be a number between 1 and 30. For 31, month must be January, March, May, July, August, October, December.' - I've tried this several different ways/shorter - open to ideas about how to simplify it

[similar, but slightly more complex argument for 29 02 2025]

[P.S. can always drop the changes for this section and revert to 'Date must be a real date' - if not confident enough to support the changes, but happy with the others]