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.
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.
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?
Yeah I know, but it also has a different use case. As far as I know RFC3339 is mostly used for programming while ISO8601 is the standard for international communication and I wish people would use it more. I have processed American invoices in the wrong month because of their date structure.
I have no reason to it, but I always write my date ISO 8601 (YYYY-MM-DD)
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.
The omitting of timezones doesn’t matter to a vast majority of the world, since most countries only have one time zone so I don’t see a reason why that is relevant in most use cases.
ISO is a general standard, it’s in the name and the RFC is created for the internet, that is also in the name/description of the RF.
Using 2025-164 can be handy, I actually use the day of the year to check what invoices from previous year are open since those are the invoices that are due 164 days or more.
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 means that 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 😊
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.
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.
Only if you want to say you have the certification for it, you can use it if you want, that is fine
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?
ISO8601 is much much looser than RFC3339:
https://ijmacd.github.io/rfc3339-iso8601/
Yeah I know, but it also has a different use case. As far as I know RFC3339 is mostly used for programming while ISO8601 is the standard for international communication and I wish people would use it more. I have processed American invoices in the wrong month because of their date structure. I have no reason to it, but I always write my date ISO 8601 (YYYY-MM-DD)
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.)
The omitting of timezones doesn’t matter to a vast majority of the world, since most countries only have one time zone so I don’t see a reason why that is relevant in most use cases.
ISO is a general standard, it’s in the name and the RFC is created for the internet, that is also in the name/description of the RF.
Using 2025-164 can be handy, I actually use the day of the year to check what invoices from previous year are open since those are the invoices that are due 164 days or more.
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 means that 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 😊
ISO is a wider standard than the RFC standards though which is only for the internet