> Despite the user’s locale being de_DE.

Surely you're not suggesting that the representation of the date that is returned by the browser should be locale-dependent? That would be a nightmare.

Well, it’d be less of a nightmare than returning it in a random locale!

At least when it’s locale-dependent I can use a look up table and parse it somehow, but getting it back in MM/DD YYYY?

I’d love to just get ISO8601 ideally, btw, but who knows if that will ever happen.

(Also, you should check out Microsoft Excel, its date type and CSV converter are both locale-dependent. Locale of the program opening the file, not the file itself. A file created in de_DE will be unusable in en_US)

Do not look at Excel when thinking about appropriate handling of dates and times.

It makes a fantastic checklist of things you shouldn't do while handling dates though!

One would think it should be simple in principle.

User side: just show/accept whatever the site owner wants, or if it's too difficult, stick to ISO 8601 (it's the standard, damn it).

JS side: just ISO 8601.

Why ISO? JavaScript has had a Date type since forever.

So Date type, then, but if we're talking input fields, they're also meant to be used with forms submitted without all that JavaScript cruft on top. So if you have to convert the date input to text for sending (or direct retrieval in code), I'd say just stick to ISO. Why? Because it's a standard.

Ahyes, I'm so stuck in JS-o-world that I forgot there's an actual text format called HTML. Thanks :-)

Why the format the site owner wants? Why not the format the user wants?

That could be a reasonable default, but you need to give the programmer control over the format, or else everyone will keep using JS-powered replacements.

WPF Datagrids have a "currency" format. This defaults to dollars regardless of your locale.