Hacker News Reader

Comment by berkes | Hacker News Reader

> ...place the user in American-style MM/DD... > No ability to force date style by design.

There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc.

The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve.

> Lets you enter nonexistent dates like 31/2

This may be an issue in specific browsers/versions/os. But enabling the "validation" by setting required and/or some other attributes, gives an error for these dates AFAICS. But, in any and all cases: server-side validation is needed anyway. You just cannot trust a value sent by a user, whether that's "validated" with sixty npm-packages and their dependencies, or by the browser.

View on HN

>The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird;

Legacy Edge used to look at keyboard locale and ignore the actual region settings. I have no idea why chromium uses MM/DD on my machine when Firefox does DD/MM. Back when $COMPANY used HTML date widgets we got a small but constant stream of complaints which we tried to triangulate (that's how I know about the Legacy Edge behaviour), but we never understood most cases.

Autodetection has been broken on a tail edge of cases for a long long time, and nobody in browser space seems to have any interest in fixing this - or worse, allowing the server to set the correct date style. The only practical fix is JS datetime widgets.

>or at least not a problem a web-dev should solve.

I think 'a not-insignificant amount of people constantly enters the wrong dates and eventually bothers support and writes bad reviews, plz fix this' is a good business cases and is something web-dev should try to handle.

>> Lets you enter nonexistent dates like 31/2

>server-side validation is needed anyway.

True, but it's a better user experience to disallow this also on client. If we only let the server do validation, why do we even bother with the SPA and the sixty-thousand one-line npm packages?

I normally use en_US but I want dates formatted as DD-MM-YYYY (or using dots, slashes etc ) and I want a 24-hour clock.

LC_TIME does not work very well with most apps.

And there is a big difference between just throwing an error if a date-time cannot be parsed because of a nonextent date, and communicating it to the user in a nice way, especially without using JS.

But the webdev has to solve this problem. Users with wrong locales and not aware of that are not very uncommon. I would also love the US to fix their stupid date format and even fully adopt the metric standard but sometimes you have to compromise and write code instead.

WRT dates, there's no "metric" standard. Not really. E.g. Belgium commonly uses DD/MM/YYYY whereas the Netherlands uses DD-MM-YYYY. Both use "metric standard" for lengths, weights etc. Same with currencies: "13,37 €" vs "€ 13,37" vs "€13,37", all depending on where in Belgium you are from, vs Dutch in the Netherlands. It's an utter mess.

Which is another reason to let browsers - the user agents - deal with this. There's absolutely no way a lonely JS dev, or even a community around something like MUI to get all this right. And they don't. There's always something broken for me with these custom elements. If it's not some US-centric web-app enforcing their MM/DD/YYYY format, then it's some "ignorant" dev being unaware that in Europe in many countries decimal separators are a comma, or that in Thailand the current year is 2566 and that this is not "too far in the future".

My bad, seems like the metric system is an old thing:

https://en.m.wikipedia.org/wiki/Metric_system

Reply on news.ycombinator.com