Comic Strips is a community for those who love comic stories.
The rules are simple:
Web of links
Issue: there are 27 different ways of writing a date.
Engineers: We most make a common standard that is unambiguous, easy to understand and can replace all of these.
Issue: there are 28 different ways of writing a date.
Joke aside, I really think the iso standard for dates is the superior one!
2013-02-27 = 1984
Rich is right, since this is the date format that sorts correctly in filenames.
And it is easily extensible to YYYY-MM-DDThh:mm:ss to include the time of day
Won't be true after 9999-12-31, however.
Oh no! The Y10K bug!
Can't wait for the Y40k bug, when Tyranids begin to infect our brains.
Who's Rich? Did you mean Randall?
...dammit, the only comics I read are XKCD and OOTS and I done fucked up.
Alt text:
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.
I am a big fan of iso 8601, I just wish it was possible to write more dates than February 27th, 2013 with it
There are several people in the comments saying they have to use 27 Feb 2013 because they work with people all over the world. I’m really confused - what does that solve that 2013-02-13 does not? I know that not every language spells months the English way so “Dec” or “May” aren’t universal. Is there some country that regularly puts year day month that would break using ISO 8601 or RFC 3339?
I think learning all abbreviations for different months in different languages is more complicated than just learning that the time is sorted from largest to smallest unit.
I propose that we amend the ISO to require the days of the week be named after their etymological roots in that language.
English Days of the Week:
Day of the Sun
Day of the Moon
Day of Týr
Day of Odin
Day of Thor
Day of Frēa
Day of Saturn
Imagine dating a meeting, "Day of Odin, May 7, 2025." Imagine a store receipt that says, "Day of Thor, June 5, 2025." Imagine telling a friend, "July 4th falls on a Day of Frēa this year!"
THIS IS WHAT WE COULD HAVE. THIS IS WHAT WE HAVE LOST. THIS IS WHAT WAS STOLEN FROM US.
We could bring it back. We could make this the norm. We could make this real. We could summon this bit of ancient magic back into our world. Let's remember what we actually named these days for! BRING BACK THE DAY OF THOR!
My goodness, some of the comments in here must come from people who thought that those writing the standard were morons who did no research.
I don’t think they’re morons…just slaves to convention and compatibility. Not many ways to get away from that and justify it.
The sane way of dealing with it is to use UTC everywhere internally and push local time and local formatting up to the user facing bits. And if you move time around as a string (e.g. JSON) then use ISO 8601 since most languages have time / cron APIs that can process it. Often doesn't happen that way though...
The BEST way is to use the number of seconds after the J2000 epoch (The Gregorian date January 1, 2000, at 12:00 Terrestrial Time)
ISO 8601 goes from 1582 (Julian calendar adoption) but can go even further with agreement about intention and goes down beyond the millisecond. Not sure why I want an integer from the year 2000 which only represents seconds.
Simplicity and precision.
Who said it was only measured as an integer? Seconds are a decimal value and many timekeeping applications require higher precision than to the millisecond. Referencing an epoch closer to our current time allows greater precision with a single double-precision floating point number.
Want to reference something before J2000? Use a negative number.
It’s independent of earth rotation, so no need to consider leap second updates either unless you are converting to UTC. It’s an absolute measure of time elapsed.
Where I live, "DD. MM. YYYY" is the standard but some old tombstones use
2013-02-27 is a weird way of writing 1361923200
ISO 8601 allows all kinds of crazy time stamps. RFC 3339 is much nicer and simpler, and the sweet spot is at the intersection of ISO 8601 and RFC 3339.
Then again, ISO 8601 contains some nice things that RFC 3339 does not, like ranges and durations, recurrences...
