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
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
The Long Now date format isn't really a new date format thou, its just a symbolic extra digit to encourage thinking long term, it really is the same format in essence.
So, even if you literally live forever, you'll definitely have amnesia.
Wait, chromosomes are data storage devices too. So life as we know it cannot continue to function forever. Some sort of massive reboot-on-the-fly would be required periodically.
I don't think this is actually correct. Like so many elegant engineering solutions, nature has taken a tough problem and turned it into a feature. Evolution actually _depends_ on the degradation of information to work. If DNA replication was perfect there would be no mutations and thus no adaptation to change.
So sure, life as we know it today will not continue to function forever - it will be even better in the future!
Do you remember any events from when you were born? What did you have for lunch on this date 10 years ago? What did you have for lunch today? We already have amnesia, via data compression :)
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
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