>And do they swap these placeholders and entered values if you change the country from US to an EU country?
The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03.
Not everyone uses the Julian calendar, or even 4-digit years. Here in Japan, this is year 4 of the Reiwa era, so you need a year picker that lets you choose the correct era (Reiwa, Showa, etc.) and then the year of that era, and of course the number of permissible years per era differs greatly. (The era reflects an emperor's term, so when we get a new emperor, we start a new era.) Then, just because this system is such a PITA and anything international doesn't use it (but everything government-related does), we need a converter that lets you convert between the Japanese standard and the Julian calendar.
I wouldn't say the Japanese calendar is used for "most" activity. As far as I can tell, the Japanese calendar is certainly used for things like government forms, but for non-government stuff, not so much. If I buy tickets for something online, for instance, the web form asks for my birthdate using the normal Gregorian calendar year. Even the government stuff is a mix; my residence card shows my birthdate and card expiration date with the Gregorian year.
Note that it i18n isn't implemented correctly by any of the browser date pickers. Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. So for anybody wanting to interact with both US sites and local sites (presumably quite a few people on the planet), they'll never be able to have appropriate browser date controls - either they get to have US controls on local sites, or local controls on US sites - and both are quite confusing, especially before you open the date control. Unopened date controls just show the client-culture-localized date, so if that doesn't match the site culture... it's going to be a mess.
Definitely not, from experience. Browser widgets need to be context sensitive, not client sensitive. There are (at least!) two simple reasons to see that: firstly, non-browser site provided controls are more common, and those are context sensitive, so it's quite unusual and surprising when a date-widget suddenly is not context sensitive merely because it's using the browser default. Secondly, date controls display dates even when unopened, and in that mode - the default, initial mode upon page load - they look like plain text with some mild styling to indicate interactivity. Dates in plain text should behave like other dates in plain text - i.e. context-sensitively.
To reiterate, there is an obvious, correct implementation here: let the site specify the content culture much like it does the language, and fall back to the user's choice when unspecified. The spec is asking for user confusion and data corruption as-is, which contributes to why usage of date controls remains fairly low.
You could also do both and have the placeholder smoothly transition between being a placeholder vs being a label. Not to self-plug but here's an example I made myself
The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03.
And always show 4 digit for years as YYYY.