8 ms·
RFC 3339 vs. ISO 8601
- 01HNNWZ0MV43FF 1y agoThe difference is that `date`, the command, and `chrono` the Rust crate implement RFC 3339, so we don't need to worry about ISO :)
- mg 1y agoMy favorite datetime format is "YYYY-MM-DD hh:mm:ss". I consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is supported by many languages and databases. It is so elegant and common that even though it is not part of a standard, LLMs started to use it when writing answers: Me: SQLite: Add 1 day and 3 hours to a date. Perplexity: SELECT DATETIME('2025-09-07 07:51:00', '+1 day', '+3 hours');
- xeonmc 1y agoIt's also the Swedish time format I believe[0] [0] https://stackoverflow.com/a/58633651 https://stackoverflow.com/a/58633651
- setopt 1y agoThat and the metric system is why en_SE is my preferred locale even though I’m not Swedish or in Sweden
- Kwpolska 1y agoWhich decimal separator does it use? Windows’ "English (Sweden)" locale uses commas.
- Symbiote 1y agoI'd assume comma, like en_DK. I'd like an en_EU definition to be added, except I went to find an official definition[1], and found the EU uses both. Elsewhere [2] it says the use of a comma is due to "technical limitations". I use en_GB or en_IE, but export TIME_STYLE=long-iso so I get ISO dates in many GNU programs like "ls". [1] https://style-guide.europa.eu/en/content/-/isg/topic?identifier=6.4-word-processor-punctuation-marks-spacing https://style-guide.europa.eu/en/content/-/isg/topic?identif... [2] https://commission.europa.eu/system/files/2023-11/styleguide_english_dgt_en.pdf https://commission.europa.eu/system/files/2023-11/styleguide... §6.10.
- progval 1y agoIt is not computer-friendly because the timezone is unspecified. And in some timezones, it is ambiguous during changes from DST to winter time.
- rocqua 1y agoLooking through the original article, this date format is only available in the RFC, and then only with the Z (which makes it UTC). Is there a timezoned version of this that is standardized?
- dijit 1y agothe number after the Z is the offset to UTC. 2025-09-07 10:57:00Z+2 would be CEST for example. (+2 hours ahead). 2025-09-07 04:57:00Z-4 would be EDT (4 hours behind UTC)
- isbvhodnvemrwvn 1y agoOffset is not the same as a timezone. Offsets change throughout the year in the same geographic areas (or don't or both do and don't)
- dijit 1y agoNo, timezones don’t change but they are swapped out by countries, offsets and timezones are an n:1 mapping. Multiple timezones represent the same offset, but those offsets are immutable. CEST will always be +2 UTC (unless something really changes politically). DST just marks that Sweden changes from CEST to CET from October to May. So Swedens offset changes, but the timezone does not change its offset.
- KronisLV 1y agoAt that point, just give me 2025-09-07T11:30:31.304[Europe/Riga] the machine can figure out the current offset and GMT itself because in any given time in the year I have no idea without looking it up.
- LukeShu 1y agoExcept for not including a timezone offset, that's one of the RFC 3339 formats.
- magnio 1y agoNot exactly computer friendly, since filenames cannot contain ":" on Windows.
- eadmund 1y agoNot all computers are Windows! And not all computer-users worry even a little bit about compatibility with Windows.
- theandrewbailey 1y agoConsidering that most normie non-tech people use Windows, compatibility with Windows is important.
- integralid 1y agoAnd cannot be longer than 8 characters on DOS.
- afiori 1y agoThen replace it with _ or anything else it is going to be equally understandable
- karambahh 1y agoOthers point out missing tz. It's also not that "user friendly": depending on their locale, users will usually expect for instance DD/MM/YYYY. Sorting by YYYY-MM-DD won't feel natural to them.
- reacweb 1y agoI am french. Everydays, we use DD/MM/YYYY or DD/MM/YY. Sometimes, I encounter YYYY-MM-DD, for example at the beginning of a document reference or in a file name. For me, it feels natural and I have no issue to make this switch mentally. The only problem I encounter is in english: MM/DD/YYYY. Hopefully less and less people are using this insane order.
- jolmg 1y ago> Sorting by YYYY-MM-DD won't feel natural to them. It's dictionary sorting.
- dvh 1y agoMine is YYYY-MM-DD--hh-mm-ss
- rdsubhas 1y agoIn most countries in the world, 24 hour time is just not human (user) friendly. Programmer-friendly for debugging? Sorry No. I don't mind the extra T in between and I'd actually like to see the timezone or zulu in logs when debugging. A counter view would be: it's half-human-half-computer inclined, but not objectively good for either.
- plusmax1 1y ago"most countries in the world" are perfectly fine with the 24 hour clock: https://en.wikipedia.org/wiki/Date_and_time_representation_by_country https://en.wikipedia.org/wiki/Date_and_time_representation_b... I fail to see why it is not considered human friendly. Its more specific, a day is 24 hours, at least I much prefer it to "am/pm".
- afiori 1y agoEspecially since there is very little logic to which 12 is midday and which is midnight does not have a clear logic
- afiori 1y agoThe extra T impacts legibility quite a lot and most systems that follow the standard either normalize everything to UTC or use a single global timezone to format everything
- jolmg 1y ago> "YYYY-MM-DD hh:mm:ss" > It is human-friendly and computer-friendly at the same time. It's not shell-friendly, because of the space. The shell being an interface between humans and the computer, this takes a chunk out of it being human-friendly and computer-friendly. You'll have to worry about quoting the thing, involve messing with IFS when making arrays of the things, extract both pieces out of text columns aligned with spaces, awk's NF wouldn't correspond with number of fields anymore, etc. Would make timestamps unnecessarily annoying to interact with. Better to at least make it an underscore. Still quite readable.
- burntsushi 1y agoIt's not elegant at all. This is a horrible idea because it doesn't account for time zone transitions. You could even end up with a time that will never appear on your clock. For example, what is the answer to in New York? SELECT DATETIME('2025-03-07 23:30:00', '+1 day', '+3 hours'); If you said `2025-03-09 02:30:00`, then that would just be wrong. Because that time never appeared on clocks in New York.
- anfogoat 1y ago> It is so elegant and common that even though it is not part of a standard ... YYYY-MM-DD hh:mm:ss seems valid ISO 8601 to me, isn't it? Neither the "T" nor the timezone are required as far as I recall. EDIT: The site says ISO 8601-1:2019 requires a T for datetimes, and that even though previous editions allowed for no T, a space was never allowed. This is shocking news to me.
- evrennetwork 1y ago[dead]
- mrinterweb 1y agoI don't think I realized how many alternative formats there are for both 3339 and 8601. Most of those alternative formats are redundant. I like that this chart shows the venn diagram of where these standards intersect.
- TheChaplain 1y agoFrom last month; https://news.ycombinator.com/item?id=28976526 https://news.ycombinator.com/item?id=28976526
- mesrik 1y agoAnyone else find it odd that C99 strftime() %F and %T equivalents did not make it later revisions ISO 8601 and RFC 3339 ? https://en.cppreference.com/w/c/chrono/strftime https://en.cppreference.com/w/c/chrono/strftime Man page strftime shows, %F Equivalent to %Y-%m-%d (the ISO 8601 date format). (C99) %T The time in 24-hour notation (%H:%M:%S). (SU) The Op linked page did not recognise these. I tried with the "%FT%T%z" which works fine with date and strftime(). I've probably used %F and %T about 20 years with no issues linux, bsd and mac that I wrote code over the years. BTW, It would be nice to see some reference or comparison how systems stdlib implementations match with these standards if there is one. One gripe I've got with RFC3999 and it's not nice to have the semicolon in filename if you intend to use it file or directory name. As it conflicts and easily becoome issue when not quoted while using rsync or any command that thinks colon (:) separates and indicates host name. I'm not sure if colon would cause issues with windows but there is chance it could as it's used indicating device name. ps. I had to implement many stdlib time.h defined functions my own between -89 - 92 for my then work as Turbo C 2.0 and 3.0/3.1 did not implement these. I recall that last time I touched these and fixed issues was when I got P.J. Plaugers The Standard C Library book when it was brand new -92. When earlier proprietary C-compliers libraries sources had not been available, that Plaugers book was was great help for many :)
- thayne 1y agoMy main complaint about RFC 3339 is it doesn't have anything for specifying a duration/period or ranges.
- drob518 1y agoEvery programmer starts off thinking that dates and times are easy. “Just do …,” they’ll say. And then you realize that ISO 8601 has more than a few ways just to write down the time, let alone manipulate it. Dates and times are a very, very deep rabbit hole. Fortunately most of the time you can get by with just local dates and times or zoned dates and times.
- bpavuk 1y agofun fact - ATProto requires you to store all the datetime strings in a format that's compliant with both RFC 3339 and ISO 8601 plus you cannot specify time without date. when I worked on datetime portion of Katproto, I had this link pinned for quite some time as a reference! ah, nostalgia... also, post factum, I find this technical decision actually good - instead of supporting all possible variations of ISO 8601 or all the variations of RFC 3339, why not just support the intersection? that way, the format will be parseable by anything compliant with any standard of these two, and you only need to handle a very small set of branches.
- tliltocatl 1y agoEverything that isn't MDY is ok. MDY - burn in hell.
- mceachen 1y agoYou need to scroll that table: 8601 has so so many formats that are just as worthless without context as MDY. %C or %h%m are egregious.
- tliltocatl 1y agoWhat makes MDY special is that it is worthless even with its normal context yet still widely used. Those you mention make perfect sense in context: %C is usefull for historians (would you rather be parsing roman numbers?) and %h%m is good for voice radio transmission. Ideally you want to tag a format so that you have context, but I guess that's a bit difficult to do without introducing localization. It's somewhat akin to the issues with less common script in Unicode - yes, those are somewhat weird, but they do have a purpose. The standard tries to encompass every usecase rather than take a YAGNI approach, which is a sensible (if opinionated) thing to do. On the contrary, MDY would appear in the same context you would expect DMY or YMD. It's only supposed advantage is that it maps English word order. But it is unsortable without parsing.