To go off on a tangent, I (and I believe I'm not alone in this) have always been annoyed at date/time handling... the leading 0 in the date of the article made

To go off on a tangent, I (and I believe I'm not alone in this) have always been annoyed at date/time handling... the leading 0 in the date of the article made me consider yetanotherdateformat. 3 parts: 'left' delimiter 'right' (delimiter not allowed in 'left' or 'right') 'left' is machine readable date format in descending order of precedence e.g. ...000CCYYMMDD-hh:mm:ss.... in UTC. 'right' is 'Human and/or machine readable date format' - which is dependent on locale, and contains the fabulous mess we already have. And the 'left' and 'right' parts should validate/reconcile each other, and if they don't - you go to 'hell'/'a re-education cent[er|re]' via a road paved with NAND gates or something. The point being it should sort properly, resulting in a kind of lame yet highly useful self contained static hash table. It's not preferred solution, but at least a step in the right direction in cleaning up the existing mess...? I also acknowledge we could still end up at the equivalent of https://xkcd.com/927 https://xkcd.com/927 Sorry for the ramble, maybe this is the final part of relieving stress from the fixing Y2K issues in COBOL and fighting with MM/DD parts of dates auto-magically swapping in early versions of Microsoft Office products... mumble, order of precedence... the USA is not the Cosmos ... mumble