Dates

[govuk-design-system]

Also known as: 'Ask users for dates'

Use this issue to discuss this pattern in the GOV.UK Design System.

Anything else

• Related to the 'date picker' component issue
• Read the draft guidance on 'date picker' component in Google Docs
• Download the code for 'date picker' from GitHub
• Related to the 'date input' component issue
• Read the draft guidance in Dropbox paper on Calendar control

[gazjoy]

For the "Year" field should users be able to enter "80" if they were born in "1980" or should there be a minimum length of 4 characters imposed?

[hannalaakso]

The GOV.UK Design System does not currently contain any specific guidance about the formatting of years as numbers. The GOV.UK Styleguide does not specifically mention it either but as it only includes examples in the 4 character format so, it would appear safer to do that.

If you have a specific use case where you think there is a clear advantage for collecting years as two digit numbers please add it here as it could definitely be something to include in our guidance.

[joelanman]

It's a good question. As Hanna says we don't currently have published guidance on using 2 digits.

Personally I think it'd be nice to support users who enter 2 digits if it's unambiguous. However I guess there's always the chance that for example if someone enters 30 in year and meant to put it in month. Requiring 4 digits would avoid that.

[ghost]

I agree with @hannalaakso that it is safer but it is clearer too. There are situations where ‘80’ could mean ‘1980’ or ‘1880’.

[adrianbiskupski]

What about use of two digit format in case of days / months ? https://design-system.service.gov.uk/patterns/dates/ suggests that there should be a single digit in situations where two-digit would have 0 at the beginning. (ie. 03 07 1999)

[ghost]

@adrianbiskupski The pattern is flexible so 03 07 1999 and 3 7 1999 should both be accepted. But you should not force leading zero on days and months between 1 and 9.

The leading zeroes are not needed. Like @joelanman said not adding them is "ever so slightly quicker, and more natural - dates in the real world, calendars etc, don't tend to have leading zeroes. It's a 'computery' pattern and we try and stay away from those."

[edwardhorsford]

It was incredibly common for people to enter two digit years when I tested passports - even with the hint text. This might be related to passports showing a 2 digit year on the document - though most users will of course know their date of birth.

It was common enough I specified that we should accept two digit years - but I think I only allowed it where we thought it was unambiguous. For dates of birth of living people it's easier than years in general - no people born in 1880 are renewing their passport now.

If we hadn't done this, I think we'd have seen at least 50% of people on the page fail validation. It's not a major fail, but one we were able to avoid.

---

For many services if you're collecting a date in recent years, you can pretty unambiguously cast it to 4 digit year. - but this would be something the service would have to think about it. I don't think we'd want to do it by default.

[edwardhorsford]

I wonder if anyone has looked at how we might offer commonly set dates. I'm currently pondering something like this:

[selfthinker]

When this pattern was in GOV.UK Elements, it had a note to explain the invalid HTML this pattern uses. It would be good to also have it in the Design System as the question about it keeps on coming up:

Note: The pattern attribute is not valid HTML for inputs where the type attribute is number. It is added deliberately to force numeric keypads on iOS devices.

[colinrotherham]

@selfthinker To double check, the latest HTML 5.1 spec still lists pattern as an attribute that must not be specified on number fields (just in case the spec was changed).

https://www.w3.org/TR/html51/sec-forms.html#ref-for-element-attrdef-input-pattern-16

Would definitely be good to add a note that we're non-standard here for a reason.

[ChazUK]

Just a small point that the example given for Date of Birth contradicts the autocomplete information that is given below it.

[amyhupe]

Hey @ChazUK – could you clarify how it does that? Thanks

[ChazUK]

@amyhupe I haven't delved to far into autocomplete before but my instinct tells me that it works on the name attribute of the input field. In the example code given for Date of Birth https://design-system.service.gov.uk/patterns/dates#asking-for-memorable-dates, the input fields are given the prefix dob, whilst in the section below that states autocomplete should be used for Date of Birth the fields are prefixed with bday https://design-system.service.gov.uk/patterns/dates#use-the-autocomplete-attribute-when-asking-for-a-date-of-birth

It might be a small point but just something I spotted.

[amyhupe]

Hi @ChazUK — thanks for explaining.

Just to clarify, the dob prefixes are used on the id and name attributes, which aren't part of the autocomplete functionality.

The autocomplete attribute uses the bday prefix as the guidance specifies. I hope that makes sense but please let me know if not.

Thanks

[ChazUK]

My bad! Just seen that the example does give that.

Thanks

[GreatState]

Have you thought about using the new input type="date" control?

[querkmachine]

@GreatState We don't use the default date input or datepicker interface for a few reasons. The ones I can think of off the top of my head being:

• Some services will only need to ask for a month and year rather than a full date. input[type="date"] doesn't support doing this, and input[type="month"] is not supported by non-Chromium browsers.
• In many situations GOV.UK users will be entering a memorable date, like date of birth, or dates in the far past, like the date a passport was issued. These are usually faster for users to type, rather than select from a picker.
• input[type="date"] inherits its display format from the user's operating system or browser locale. While there are situations where this may be preferred, it can lead to confusion if a user has a misconfigured machine, as they may be trying to enter a UK date format when their OS is configured to use the American date format. This moving target of accepted formatting would also make it difficult to provide appropriate guidance and support to users.
• The GOV.UK Design System currently provides 'compliant' support to IE11 (users should receive the same experience as modern browser users) and 'functional' support for IE8, 9 and 10 (users should receive a functionally comparable, if not identical, experience). To create the same experience as input[type="date"] on IE would require us to implement input masks and a custom datepicker (which is a whole other kettle of fish).

We do suggest using a picker in some circumstances as an enhancement over a text input, but we don't currently provide a component for doing so in the Design System.

[calvin-lau-sig7]

We’ve chosen to prioritise ‘Choosing a date’ as one of our Upcoming components and patterns.

If you’d like to help, join the GitHub discussion page for Choosing a date. We’ve created it to make it easier for the community to discuss issues and options.

[haynes-dev]

I'm wondering if anyone has any use cases they could share for calculating minimum age based on date input e.g. must be 18 years or older.

I'll explain the context, as its not the calculation to work this out that's the issue.

I'm putting together an automated client side validation script file (working on PowerApps portals connected to D365 so server-side validation is virtually none existent other than Microsoft throwing a common data service error with no context), where the html identifier for the component would be passed into the a validation function and it does various things based on the type. For example, date input validation might be:

• Complete null check (if required) - "Enter your date."
• Missing day/month/year - "Enter your day/month/year"
• Valid day/month/year - "Date must contain a valid day/month/year"

I was hoping there might be something already built in to the govuk-frontend js (a bit like the max character attribute in text area count container), but I can't see anything in the documentation, so I'm trying to think of the best way to pass this into the validation functions if it's required.

The only option I really have at the minute is to add something like a custom min-age attribute to the html component, but as we're talking about dates I might also need something custom for min and max date ranges. A min-date attribute wouldn't help in the specific use case of min-age because it would to be dynamic from date now. I don't want to have loads of optional attributes if I can help it. Any advice or use cases would be appreciated!

[36degrees]

Hi @haynes-dev,

It sounds like you're trying to use validation to check whether someone is eligible for something, which is not something we'd recommend. If the user being younger than 18 means they're not eligible, you should instead take them to a page which tells them they’re not eligible and gives them useful information about what to do next.

The date input component does not include any JavaScript and the expectation is that any validation would be carried out server side. I'd generally be wary about implementing business logic in client-side JavaScript as the user may be able to bypass such checks by disabling JavaScript or by modifying the page using dev tools.

It sounds like the constraints of PowerApps might make server side validation like this difficult or impossible, so I'd consider if there are other ways you could design the service that don't require you to calculate their age from their date of birth, like asking for their age or asking them to declare that they meet eligibility requirements some other way.

Hope that helps.

[haynes-dev]

@36degrees thanks for that! It's not that the server side validation doesn't exist, it does (usually just configurable when creating the column in the UI in Dynamics), it's just that Dynamics doesn't return anything useful to the client. For example, if phone number is not a valid telephone format it will just be a very generic message like "Common data service error" when attempting to submit data to the database. The idea behind the client side JavaScript is to at least attempt to show something useful to the user upfront before attempting to submit. Even if someone were to bypass this the user still wouldn't be able to continue, they just wouldn't get an error message that actually means anything to them.

I'm aware of course I could send the data elsewhere first for validation before attempting to submit the data to Dynamics, but I guess that would probably defeat the point of spinning up a quick PowerApps Portal against a Dynamics instance in the first place.

I should add, minimum age is just an example. I'm just trying to cover all potential scenarios upfront to save having to update it too often 😃

[querkmachine]

@haynes-dev On this specific point:

Valid day/month/year - "Date must contain a valid day/month/year"

Often, it's better to validate a date as a whole value rather than try to highlight which of the day, month or year is specifically incorrect.

31/04/2023 isn't a valid date, as April only has 30 days, but it isn't really possible to determine whether the day is wrong (maybe the user made a typo and meant 21/04/2023?) or the month is wrong (maybe they meant 31/05/2023?)

Similarly, 29/02/2023 isn't valid—but 28/02/2023, 29/03/2023, and 29/02/2024 are.

There are naturally places where you can do this (day can never be greater than 31, month can never be greater than 12, in any circumstances), but these situations will still be caught by validating the whole date as a single value, so it's well worth doing it that way!

[philip-harper]

Just wondering, has there been any User Research into the Month field being a three letter abbreviation Jan, Feb, Mar etc.?
Was thinking about accessibility and those with dyscalculia and the challenges of translating numbers into months of the year. 🤔

[robinparker]

Hi there, I'm just wondering if anybody has run into any accessibility issues with error validation on the Dates pattern?

A recent DAC audit on our service flagged the fact that, if just one or two of the three text fields contain an error, our error message still reads as if all three fields require attention. I think DAC's concern is that this could lead to confusion for screen reader users;

[joelanman]

@robinparker it looks like the error message is wrong there according to the patten:

https://design-system.service.gov.uk/components/date-input/#if-the-date-is-incomplete

I think it should be 'Date of birth must include a year'

[robinparker]

@joelanman Thanks Joe, I'll feed that back to our devs

[RichardBradley]

We do suggest using a picker in some circumstances as an enhancement over a text input, but we don't currently provide a component for doing so in the Design System.

Is there any update on this aspect of the guidance?

If we want to offer our users a date picker popup or component, is there a good one?
The guidance here still doesn't offer one made by or approved by govuk

We have recently found https://designsystem.gov.scot/components/date-picker which looks good. You could adopt that?

Do you still not favour the native date picker via <input type=date>?

[JodiB-TPR]

Howdy.

We've just done a round of accessibility user testing where our date example was 30 9 2025. The issue our participants ran into was that this was read out by screen readers as '39 2025'.

We propose that you amend the guidance on the Dates page to advise against using days ending in zero. The guidance currently says, "If you give an example date, use 13 or more for the day and 9 or less for the month - for example ‘27 3 2007’. This helps users enter the date in the correct order and shows them they do not need to include leading zeroes."

Consider instead,
"If you give an example date, use a day of 13 or more and a month of 9 or less. Do not use a day that ends in zero (such as 20 or 30). Some screen readers will merge the zero with a single-digit month, misreading "30 9" as "39".

For example, use ‘27 3 2007’. This helps users enter the date in the correct order, shows them they do not need to include leading zeroes, and ensures assistive technology reads the numbers correctly."

I've already proposed this content change via the proper channel. :)

[NickColley]

@JodiB-TPR thanks for this! Could you share with us what screen readers were used and with what web browser so we can reproduce this behaviour?

[JodiB-TPR]

@NickColley
NVDA while using Firefox on a Windows machine.
It depends on how quickly the verbosity is set. The direct quote from a participant: "The only slight complication with the example text you've given is that if you're listening to it really quickly, it says '39, 2024'. So, is it '30, 9' or is it '39'?"

I can replicate it in other browsers using both NVDA and Narrator.