<input type="date"> is automatically formatted based on the user's locale.

suzzer99 2 hours ago | parent | next [-]

Input type=date also just saves the day, month and year with no timezone information, which makes sense since the widget doesn't show any and context determines if the date should be in the user's timezone or a fixed timezone (like an event start date or a flight departure). But if you don't immediately convert that date to an ISO date and instead save it to the DB as yyyymmdd, you're in for a world of hurt trying to display date/times throughout the site. I inherited a project like this and have spent countless hours wrestling with nightmare timezone issues.

▲

8organicbits 7 hours ago | parent | prev [-]

This is still a partial solution as the user needs to know that their locale is being used and know how their locale is configured to understand the format. This is most problematic on shared computers or kiosks, especially when traveling.

	▲	stephbook 7 hours ago \| parent \| next [-]
		I don't even know my locale. Is is the device display language, the keyboard input language, my geo location, my browser language, my legal location, my browser-preferred website language, the language I set last time, the language of the domain (looking at amazon.co.uk), the language that was auto-selected last time for me on mobile or... something else entirely?
	▲	embedding-shape 6 hours ago \| parent \| prev [-]
		I mean, once in a different country, you either experience the locale shock once then adapt, or you've seen it before and kind of know what to expect. And for the rest of the users who have no idea about locales, using whatever locale they have on their computer might be technically incorrect for some of them, but at least they're somewhat used to that incorrectness already, as it's likely been their locale for a while and will remain so.