Standards shouldn't be behind a paywall

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.
- Thanks /u/OsrsNeedsF2P!
- I'm a Linux nerd and even I don't get this 😭

A space is more problematic than a T tho
- Skill issue
  
  For a skilled pro like you I suggest using epoch time for everything
  
  Any other day I'd see this get laughs, but I guess people are removedier this time of day.
  I'd write down the ISO timecode I'm talking about, but I can't afford it.

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.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.
- I'm not exactly fond of the space either, but man, the T is noisy. They could've gone with an underscore or something, so it actually looks like two different sections.

- 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
- It's really a skill issue if replacing T by [T ] in your regexp is hard
  
  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.
  
  This is the killer for me. Most people promote ISO 8601 as a "definitive" date structure, when it actually supports a lot of different formats. What they actually want is usually RFC 3339.
  
  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
  
  Week numbers are convenient for projects in which key delivery dates are often expressed in his many weeks out they are.
  
  wtf what is that gross
- That Z is doing a lot of work.
  
  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.
- 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
- Both are valid (if you'd add seconds) in both RFC 3339 and ISO 8601, but timezone support is the same here and there...

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.
- You HAVE to read the spec if you want to be compliant, you can't just hope every detail is on wikipedia
  
  Also, even if you fully respect the specs, I assume you can't get certified as "compliant" by ISO if you didn't pay for the specs ?
  
  "HAVE" to like Germans HAVE to have their driving license to drive?
- If you want to be compliant for a standard you need to have a copy of it. Luckily it's only companies that really need to buy them
  
  Which means the companies using the specs pay the company making the specs for everyone (companies and people) to use.
  That sounds fair, but I wouldn't be surprised if capitalism fucked it up anyhow.

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
  
  Please be serious and give me that list! Please be real!
  Edit: guys, if they don't answer, they might just missed the question. They might be real. BELIEVE!!!
  
  Do you care to share them?
- Linux sex tips approved

I don’t even know what ISO 8601 is, but I agree with the sentiment
- https://en.m.wikipedia.org/wiki/ISO_8601
  Date format that is both human readable and for the most part sortable as strings (assuming you are using the same time zone).
- Same

Well, they cover very different formats: https://pbs.twimg.com/media/FdzPYu-UAAADHEq.jpg
- TIL, didn’t know that

Relevant XKCD: https://xkcd.com/1179/
- Counterargument: https://xkcd.com/927/

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.
  
  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.
- What he means is, if you want to download the document from ISO that describes the standard, you have to pay a fee. Here's their store page: click.
  It's about 190 USD for a 38 page document describing the rules of the standard. There's another document with extensions for a similar price. Quite pricey for a PDF file obviously, and the RFC is free to download.
  On the other hand, no one in the history of time has gone "hmm, I don't know how ISO-8601 works, let me go buy this document from the ISO store to figure it out." Most people just call datetime.isoformat() or whatever their library function is called.
  
  Ah thanks for the clarification! Very informative

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.
- Too confusing. How about ymh-yMy_myM-h
  
  Maybe we could use different letters. Something only ISO knows and jeeps in their spec.

iSO
- savage

RFC2795, because the IETF guys work hard, and then play hard on April fools.

The space is SO MUCH BETTER

- https://programming.dev/c/programmer_humor is leaking.
  They're both standard for the format of dates and times, like 2023-12-13 15:52:21. I guess one of them isn't free, though? TIL.
  
  Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !programmer_humor@programming.dev

- 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.