After all the self-important blowhards in the committe were satisified that they had put their fingerprint on the ISO8601 document with bullshit like “year-month-week” format support and signed off, they went home.
The rest stayed behind, waited a few minutes to be safe, and then quickly made RFC3339 like a proper standard.
ISO8601 is YYYY-MM-DD nothing to do with weeks and isn;t the only difference of RFC3339 that you can use a space instead of a T in between the date and time?
Also RFC3339 is only an internet standard while ISO is a generally international standard?
No idea what you based those claims on, but the spec itself (I have the pdf) and Wikipedia’s summary disagree. ISO8601 allows for YYY-MM-DD yes but it allows for a bunch of silly stuff.
Let’s not forget that technically you have to pay for ISO8601, despite it being nearly useless as a standard because it allows several incompatible formats to coexist.
So, first epoch time. It’s a pretty robust standard, covers many use cases, has few edge cases… but it’s specifically for machine usage, since it’s not human readable and it’s not reversible into the past (pre-1970).
ISO 8601 (depending on the annum), by the text of the documentation, these are all valid dates:
2007-04-05T14:30
2007-04-05T12:30−02:00
2007-04-05T14:30Z
200704051430
07-04-05T14:30
2007-95T14:30
Etc.
RFC 3339 (& RFC 9557, it’s newest modification) is actually a subset of ISO 8601 and is far more prescriptive. For example you must have a timezone designator. You must have a separator between the date and time. You must use a dash between date elements and a colon between time elements. You can easily add standardized subseconds.
2007-04-05T12:30−02:00
2007-04-05 14:30Z
This message RFC 3339 is much easier to parse and use by both machines and humans.
This is delicious, and I can’t say thank you enough. I like this a lot.
If anyone has any insight on more superior standards or subsets of these, please inform me.
This made my day tho 😊
Were you mostly joking or is there a utility to this? Genuinely curious as someone that finds confusing things slightly more memorable in a really backwards way
It’s a flexible standard. 2026-05-10T10:06:09.426792Z, 2026-05-10 10:06:09.426792Z,2026-05-1010:06:09.426792, and 2026-05-10 all conform to the standard.
I know. I started using the format with periods back in the 90s, before I knew of the standard, and at this point doing it with periods is muscle memory. That’s not meant as an excuse, just an explanation. The excuse is laziness.
I rather have somebody write their invoices at DD-MM-YYYY cause there is a bigger chance it will most likely not be an invoice from a North American company which notriously cannot make proper invoices and most software that actually scans and processes invoices is based on the European standaard DD-MM-YYYY or on ISO8601.
Btw this is how it’s used in some countries (eg., Hungary, Japan, China, and a few others from Asia). All other date formats are very strange and confusing for us
Waiting for the ISO 8601 & 9001 gang to show up and promote YYYY-MM-DD.
RFC 3339 if you please. Let’s be prescriptive.
After all the self-important blowhards in the committe were satisified that they had put their fingerprint on the ISO8601 document with bullshit like “year-month-week” format support and signed off, they went home.
The rest stayed behind, waited a few minutes to be safe, and then quickly made RFC3339 like a proper standard.
This is what RFC3339 vs ISO8601 feels like.
ISO8601 is YYYY-MM-DD nothing to do with weeks and isn;t the only difference of RFC3339 that you can use a space instead of a T in between the date and time? Also RFC3339 is only an internet standard while ISO is a generally international standard?
No idea what you based those claims on, but the spec itself (I have the pdf) and Wikipedia’s summary disagree. ISO8601 allows for YYY-MM-DD yes but it allows for a bunch of silly stuff.
https://en.m.wikipedia.org/wiki/ISO_8601
Both “2025-W24-4” and “2025‐163” are valid representations of today’s date in ISO8601.
(Also the optional timezone makes it utterly useless.)
ISO8601 is much much looser than RFC3339:
https://ijmacd.github.io/rfc3339-iso8601/
Let’s not forget that technically you have to pay for ISO8601, despite it being nearly useless as a standard because it allows several incompatible formats to coexist.
Fucking wild.
While a fucking stupid concept, it’s nice that this particular format has a monetary deterrent.
Anyone help enlighten me about whatever this and unix epoch are getting at? Are these really more specific/better than iso 8601 and why specifically?
Happily!
So, first epoch time. It’s a pretty robust standard, covers many use cases, has few edge cases… but it’s specifically for machine usage, since it’s not human readable and it’s not reversible into the past (pre-1970).
ISO 8601 (depending on the annum), by the text of the documentation, these are all valid dates:
Etc.
RFC 3339 (& RFC 9557, it’s newest modification) is actually a subset of ISO 8601 and is far more prescriptive. For example you must have a timezone designator. You must have a separator between the date and time. You must use a dash between date elements and a colon between time elements. You can easily add standardized subseconds.
This message RFC 3339 is much easier to parse and use by both machines and humans.
This page (reddit, I know…) has a great summary, and so in the interest of knowledge and attribution I’ll link it: https://www.reddit.com/r/ISO8601/comments/p572xy/rfc_3339_versus_iso_8601/
This website allows you to more directly compare the two interactively. https://ijmacd.github.io/rfc3339-iso8601/
This is delicious, and I can’t say thank you enough. I like this a lot. If anyone has any insight on more superior standards or subsets of these, please inform me. This made my day tho 😊
Hello I’ve arrived
Whoo! ISO-8601 fan club!
DD-MM-YYYY-HH-MM-SS
Makes no sense!
I prefer the alphabetical date format
DD-HH-MM-SS-mm-yyfor maximum confusionWere you mostly joking or is there a utility to this? Genuinely curious as someone that finds confusing things slightly more memorable in a really backwards way
Yes I was joking, get a random timestamp in this format and you have no idea what it’s referring to.
DD:HH:MM:SS:mm:yyis even better because it could be a MAC address.o7
I’m doing my part!
I’m now imagining a child who must write
2026-05-10T10:06:09.426792Zon all of their tests.Microsecond precision is fine for most use cases, but I teach my kids to use nanoseconds.
It’s a flexible standard.
2026-05-10T10:06:09.426792Z, 2026-05-10 10:06:09.426792Z,2026-05-1010:06:09.426792, and2026-05-10all conform to the standard.They should also add a timezone since most of us don’t live at UTC zero timezones -> 2012-12-28T18:12:33+09:00
They did; the
Zat the end denotes UTC.My point was not everyone is just at UTC zero but sure Z is also a timezone.
YYYYMMDD, scrub out the excess fat!
If only there were some international standards organization to make a decision for us!
I use periods. YYYY.MM.DD
https://m.xkcd.com/1179/
I know. I started using the format with periods back in the 90s, before I knew of the standard, and at this point doing it with periods is muscle memory. That’s not meant as an excuse, just an explanation. The excuse is laziness.
Best excuse
It’s the only way that makes sense
Hello from Hungary ! We should also democratize the Surname GivenName format
Szia. We should indeed.
sup
YYYY-MM-… well, ya know the deal…
That’s … why I’m here
Anyone that gives me a document or receipt or invoice with a date formatted DD-MM-YYYY should have a tire iron swung at their thighs
I rather have somebody write their invoices at DD-MM-YYYY cause there is a bigger chance it will most likely not be an invoice from a North American company which notriously cannot make proper invoices and most software that actually scans and processes invoices is based on the European standaard DD-MM-YYYY or on ISO8601.
As a big ISO 8601 guy myself, I request explanation of this 9001 addition? Never heard of it till now and am optimistic
Seconded. Not coming up with much when trying to find out more about it.
ISO 8601/RFC-3339 (Unix Epoch also acceptable) gang reporting in.
deleted by creator
ISO thirsty!
Btw this is how it’s used in some countries (eg., Hungary, Japan, China, and a few others from Asia). All other date formats are very strange and confusing for us