Hacker News Reader

Comment by otherme123 | Hacker News Reader

I found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of "<input type='date'>" you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget about it forever (e.g. no updates, no CDN).

View on HN

A lot of those date and time pickers will fail WCAG testing as well.

In most cases, GDS now use just 3 text fields for day, month and year, but recommend pickers for dates close to today's date e.g. for booking an appointment, because a picker is easier if you don't know the exact date without reference to a calendar.

Sadly they don't currently have a recommended picker, but there's a useful discussion of what has been tried here:

https://github.com/alphagov/govuk-design-system/discussions/...

The native date input is terrible. Not the actual native control, which is usually okay, but the field itself. You can't even format the date! That's the number one reason I always use some datepicker library in combination with a regular text input.

IMO, you (the web developer) should not be formatting the date shown in the input widget. The input should be shown to the client following the system settings, so a US browser would show MMDDYYYY, while an European browser would show DDMMYYYY. And the field is correctly (IMO) normalizing all of them to ISO-8601 (YYYYMMDD) before sending it back.

And I have this opinion because I had to deal before with format configuration and normalization before saving to the database, when using a JS library. Now I just drop a "input type=date", and I know I'm going to get the ISO formatted date at the backend.

If my entire application used YYYY-MM-DD everywhere, it can be very confusing for users when the input suddenly uses something else. And often the locale or system settings are incorrect anyway. When I an working on a Dutch site with a Dutch locale and lang settings, then dates should be shown according to the Dutch locale, not according to whatever system of browser locale there is.

I always keep my OS and browser in English (makes searching for error messages sooo much easier) but I hate that I need to change my OS settings just to get Firefox to display the date in a proper way on some site.

If it works for you, I guess it's OK.

My apps usually deal with non-technical people (thus ISO in the browser input is out of the question), and sometimes spread at least between Europe and US (so people would enter MMDDYYYY and DDMMYYYY, and keep in mind that some dates work validate for both formats, namely every 12 first days for each month). Behind the scenes everything is ISO and UTC, but everyone gets their preferred format in the frontend.

I'm not getting your Dutch example. If I'm in the US and use MMDDYYYY almost always, and want to access some Dutch site, what date format would you show me in the input form? DDMMYYYY only because the backend is hosted in Europe? You will get wrong dates (e.g. 11/1/2024 for the first day of november, your system will store 11th of january) for at least half the US visitors.

Or maybe you are talking about "dates displayed" instead of "dates input", which is a different problem?

To be honest I would expect dates on a Dutch site to be shown in dutch format, just like I expect dates on American sites to be formatted in the US way.

Lets clarify a bit here. There are two different problems:

- Date display. I prefer to show it in the browser preferred format, but in the end what you say is also OK. It's a very minor issue.

- Date input. I would never force a format to the user, it there is any chance people from different locales can access the web. The correct way, IMO, is "input in the preferred browser format, send data as ISO". Any other combination would cause errors, e.g. "input in the preferred browser format, send data in that format" and you'll get wrong dates in the backend, or need to do a lot of gymnastics to avoid them. "input in server locale, send data in any format", and you'll get wrong dates from people used to any format that is not your server locale that happens to validate in multiple locales. "input in ISO, data send as ISO", you'll get users upset because "YYYY-MM-DD is stupid, use MY locale instead".

How do we know when a site is Dutch? Maybe check the URL to see if the TLD indicates?

I'm in agreement with showing/inputting dates in the users' regional setting.

<html lang="nl_NL"> of course

Reply on news.ycombinator.com