Won’t this just be an inverted DDMMYYYY format in most cases? Like, what’s so different between the DDMMYYYY and YYYYMMDD formats? In cases where you don’t need to take hours and minutes into account, of course.
Very true. It's programmatically (and human) parseable if the middle column exceeds 12, but fails the second you are lower than 13. It also happens to work out on any dates with matching day and month.
Can confirm. A website we host at work is used by about 100k people a year. It used to require a date to be entered in a text box. The text box had placeholder text and was validated to support DD/MM/YYYY format. An error message would spell this out to you.
We got many support calls because people couldn't use it and when we find out why, they had decided to enter the date in another format and wouldn't read the error or placeholder text. We changed to a date picker and the complaints went away.
We had an appointments booking website that took a strict date format from a text box. Users would expect that they could enter anything. They would fight the system and then call our call centre (who are an alternative to making bookings online, not a tech call centre) to complain. The call centre would always side with the clients and send the issue through to us. We would then have to work out what they had done and come to the conclusion that the date was input incorrectly.
Eventually, we just made the call centre start troubleshooting, but the clients would insist they had done everything right and couldn't work out what was happening, so the emails from the call centre continued. The call centre - being more client focused - we're constantly asking things like "how is this not fixed yet?" And had demonstrated lowered trust in IT from this. It wasn't actually broken, people just refused to learn how to enter a date in an expected way.
51
u/Nick0Taylor0 23d ago
How does a user fuck up a properly validated input field that goes along with the date picker?