- ISO 8601 is paywalled
- RFC allows a space instead of a T (e.g. 2020-12-09 16:09:…) which is nicer to read.
Top post of the hour is about an RFC from >20 years ago.
This is worse than the Linux stuff.
Y’all a bunch of nerds
You’re not wrong
Room for one more
One of us, one of us, one of us
Being a nerd is fun.
I’m a Linux nerd and even I don’t get this 😭
You’ve just become the nemesis of the entire unix-like userbase for praising the space.
What’s the issue with the space?
On the command line, space is what separates each argument. If a path contains a space, you either have to quote the entire path, or use an escape character (e.g. the
\character in most shells, the backtick in Powershell because Microsoft is weird, or the character’s hexadecimal value), otherwise the path will be passed to the command as separate arguments. For example,cat hello world.txtwould try to print the fileshelloandworld.txt.It is a good practice to minimize the character set used by filenames, and best to only use English alphanumeric characters and certain symbols like
-,_, and.. Non-printable characters (like the lower half of ASCII), weird diacritics (like ő or ű), ligatures, or any characters that could be misinterpreted by a program should be avoided.This is why byte-safe encodings, like base64 or percent-encoding, are important. Transmitting data directly as text runs the risk of mangling the characters because some program misinterpreted them.
but what does the command line matter for dates? sure every once in a while you’ll have to pass a date as an argument on the command line but I think usually that kind of data is handled by APIs without human intervention, so once these are set up properly, I don’t see the problem
rsync -a "somedir" "somedir_backup_$(date)"If the
datecommand returns an RFC-3339-formatted string, the filename will contain a space. If, for example, you want to iterate over the files usingfor d in $(find...)and forget to set$IFSproperly, it can cause issues.Both arguments are surrounded by
", which should be space-safe.At least in the shells I use, putting
"makes spaces inside paths a non-issue.For the
rsynccommand, yes. But this:for d in $(find . -type d); do echo "$d" donewill process the space-separated parts of each path as separate items. I had to work around this issue just two days ago, it’s an obscure thing that not everyone will keep in mind.
Hm, I guess I just don’t agree that CLI usablity comes before readability.
Again, it’s not just CLI, it’s an insurance against misinterpreted characters breaking programs.
honestly, if a space breaks your program, it’s kind of a shit program.
deleted by creator
allows, not requires. It basically means you can use space instead of T when showing it to end users and any technical person can just use T
deleted by creator
The amount of things allowed by ISO 8601 is even more than what’s allowed by RFC 3339, if you take the time to look at https://ijmacd.github.io/rfc3339-iso8601/
The difference:
2023-12-12T21:18Z is ISO 8601 format
2023-12-12 21:18 is RFC 3339 Format
A small change
Both are valid (if you’d add seconds) in both RFC 3339 and ISO 8601, but timezone support is the same here and there…
I definitely don’t agree that the RFC is easier to read, the two numbers can appear to be one at a quick glance without a separator.
Yeah I like a girl who is firm on her choice of date time format…😂😂😂😂
I personally have a list of 14 RFCs I won’t compromise on when it’s a first date
Do you care to share them?
Linux sex tips approved
Its funny because everything about ISO 8601 is covered on its Wikipedia article. Very few people need to spend the francs to need the spec.
wtf does this even mean?
This is about the old argument around how date strings are formatted.
MMDDYYYY vs YYYYMMDD, spaces or hyphens may differ. It’s an old and passionate argument (mostly due to the American approach of starting with the month being insane)
Both ISO8601 and RFC3339 are YYYY-MM-DD. The difference is in how the date and time are separated.
Than you! I was shooting from the hip half asleep (the classic ‘gosh I’m so clever’ moment for me…)
I’ve worked with this one project for so long I can now read +%s timestamps.
ISO standards need to be purchased to be viewed, RFCs are freely available requests for comment. The RFC 3339 format is effectively the same is the ISO format, except RFC 3339 allows for a space between the date and time components whereas the ISO format uses a “T” character to separate date and time components.
If you want to get real weird, RFCs are not standards but rather a request for other participants to comment on the proposal. RFCs tend to be pointed towards as de facto standards though, even before they become a BCP or STD.
Yeah… I have no idea what any of that means either. I’m sorry I caused you to write all that out.
How could it be paywalled? I’ve never heard of anyone paying ISO to be able to write the date and time in a handy way.
We need a better one…
Ymd-ymd-yhms-yhms
Much clearer and easier for programmers.
Right now, it’s 210-024-200-379
Am programmer. Idk wtf that is. But if it converts easily to a datetime object, or if I can easily parse the parts out of it, I’m all for it. Idgaf if it’s easy to read as-is. Just make it efficient and make it sort predictably, and I’m all for it lol.
The space is SO MUCH BETTER
deleted by creator
No?
In ISO 8601:2004 it was permitted to omit the “T” character by mutual agreement as in “200704051430”, but this provision was removed in ISO 8601-1:2019. Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.
