> in the format 02/18/1993

Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that it's the latter, but that convention isn't universal. I'd recommend YYYY/MM/DD as a less ambiguous format, but I don't have a perfect answer.

▲ kriops 5 days ago | parent | next [-]

Furthermore, require dashes over slashes to signal that you are expecting ISO-8601 compatible dates, i.e., YYYY-MM-DD. Most users does not know the standard even exists, but it serves as an affordance that it is different from dd/mm/yyyy, etc.

▲

PaulHoule 5 days ago | parent [-]

Those ISO-8601 dates are great for date processing with primitive tools such as GNU sort or awk since they sort lexically, at least if you're not comparing dates in different time zones.

▲

titzer 5 days ago | parent [-]

ISO 8601 is the way.

▲

homebrewer 5 days ago | parent | next [-]

You must mean RFC 3339.

https://ijmacd.github.io/rfc3339-iso8601/

	▲	bobmcnamara 5 days ago \| parent [-]
		Out blasphemous temporal demon! Out!

▲

tshaddox 5 days ago | parent | prev | next [-]

Yes, except for all the completely unhinged stuff in ISO 8601. You probably do not want to deal with durations, or repeating intervals, or even week dates and ordinal dates.

▲

cyanydeez 5 days ago | parent | prev [-]

alas, the user doesnt know the way...

	▲	PaulHoule 5 days ago \| parent [-]
		That part is easy. Use a date picker of some kind https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... or a text field with some code that converts vernacular dates to a structured format. I don't think users are going to be too weirded out at seeing "1997-04-15" and will probably learn to use that natively. The hard part is that a lot of devs aren't aware that there's a standard and that standard is superior to the alternatives.

▲ senfiaj 5 days ago | parent | prev | next [-]

Every time I see an input date string in XX/XX/YYYY format I get a micro PTSD flashback. This cannot be parsed reliably and is locale dependent. The standard date format is YYYY-MM-DD (it's also the date part of the ISO time format). Raw text inputs should be avoided as much as possible, date/time pickers should be preferred.

▲ hanche 5 days ago | parent | next [-]

Even worse with just two digits for the year! 01/02/03 could be 1 Feb 2003, or 2 Jan 2003, or 3 Feb 2001. Let’s just be thankful no one ever uses any of remaining three permutations.

▲ oneshtein 4 days ago | parent [-]

  $ LANG=C date --date="01/02/03"
  Thu Jan  2 00:00:00 EET 2003

  $ LANG=de_AT.utf8 date --date="01/02/03"
  Do 02 Jän 2003 00:00:00 EET

  $ LANG=zh_HK.utf8 date --date="01/02/03"
  2003年01月02日 星期四 00:00:00 EET

	▲	1718627440 2 days ago \| parent [-]
		That only shows that date only converts on output and not on input.

▲ dragonwriter 5 days ago | parent | prev [-]

> The standard date format is YYYY-MM-DD (it's also the date part of the ISO time format)

Strictly, it is the extended form of the ISO 8601 calendar date format. (The basic format has no separators.)

ISO 8601 allows any of its date formats (calendar date, week date, or ordinal date) to be combined with a time representation for a combined date/time representation, it is inaccurate both to call any of the date formats part of the time format, and to call the calendar date format the format that is part of the combined date/time format.

(There's a reason why people who want to refer to a simple and consistent standard tend to choose RFC-3339 over ISO 8601.)

▲ happytoexplain 5 days ago | parent | prev | next [-]

This isn't really relevant to the parent's topic though, aside from UX. The UI can tell the user which is the day and which is the month. The logic layer knows the format explicitly.

▲ jack_pp 5 days ago | parent | prev [-]

Pretty sure they force the user into that format so that shouldn't be an issue