Hence why I quoted
@William Lancee
On a related note: we had to handle this for a program that accepted user input in the USA (ie month first) and almost everywhere else (day first) except for Japan (year first) and we solved it by having a setting that specified the order of the date components, and another setting that enabled automatic updating of the order setting according to actual input dates ie if a component was > 31 then it couldn't be a month or day value, and if it was > 12 then it couldn't be a month value.
Worked great, unless you had a workshop with people who thought in different date styles.
Also handled dates like 20/6/7 (and 200607 and 607 and 0720).
On the output side, we defaulted to using Jan..Dec for the month component, but then we needed to cope with non-english variations.
Internally all dates were stored as an 8 digit (32-bit) number yyyymmdd. Zero problems with y2k rollover. Lol heck just realised we're already a quarter of the way to y21c rollover.