- 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
A space is more problematic than a T tho
You’ve just become the nemesis of the entire unix-like userbase for praising 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.txt would try to print the files hello and world.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
allows a space instead of a T
That’s a bug not a feature
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
Development wise, It’d be better if it’s required not allowed. Best case scenario, it’s just another redundant if statement.
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/
This is the most junior developer comment I’ve seen in a while.
Nobody that’s competent thinks that’s shit is hard. That’s not the point.
The point is, it makes it easy to make mistakes. Somebody might see all of one type of strings, assume that’s the format, and forget to enclose the thing in quotes, causing mysterious bugs years later when a differently created date filters into the system. You might have a regex error, you might split incorrectly, you might make a query that works the wrong way and gives an incorrect aggregate, and none of that is due to lack of skill. It’s due to not knowing it’s the rfc standard, not the iso. It could be due to not even realizing the rfc allows for that or is different.
Software engineering in practice is not about making sure there is at least some way for people to use your library/standard/pattern. It’s about making sure the way to do it that’s most intuitive/obvious is also foolproof, easy, and efficient. Adding the space makes debugging harder and adds footguns which is exactly what good software engineers want to stay away from. Otherwise we’d all be writing in assembly. But since you aren’t, maybe you are the one with a skill issue. Either that or you really misunderstand this field.
The difference:
2023-12-12T21:18Z is ISO 8601 format
2023-12-12 21:18 is RFC 3339 Format
A small change
ISO 8601 also allows for some weird shit. Like 2023-W01-1 which actually means 2022-12-31. There’s a lot of cruft in that standard.
Doesn’t the ISO also includes time periods? Because if it does, those are amazing.
Without any explanation, you should be able to decypher these periods just by looking at them:
- P1Y
- P6M2D
- P1DT4H
- PT42M
Z indicates UTC. Alternatively,
2023-12.12T21:18-05 for time zone as central. The UTC time zone code at the end just tells you where the time is taken from. Usually Z is used since, well, it’s “universal,” but having a +13 or -06 or whatever else brings context, and allows computers to synchronize the string of text into a comparable time for event logs and such.
Yes. The RFC is missing something that explicitly indicates the time zone. The Z is a great unambiguous way of saying “yes, this is UTC.”
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.
But there is a separator between the numbers: the same one that also very reliably separates the words in this comment
- A single separator is better than a choice of separators to mean the same thing.
- A space is not as apparent in a large log of data as a capital T
- Human language is not as strict as a programming language. There is a reason you see people still using “alot” and “a lot”. That just proves it’s easy to overlook and commonly happens.
