• ISO 8601 is paywalled
  • RFC allows a space instead of a T (e.g. 2020-12-09 16:09:…) which is nicer to read.
  • OsrsNeedsF2P@lemmy.ml
    13523·
    1 year ago

    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

        • datelmd5sum@lemmy.world
          4·
          1 year ago

          Cassandra uses epoch milliseconds for timestamping snapshots. This means that each node will have a different name for the same snapshot. Trivially solved with truncating the timestamp with * wildcard, but just… why?

      • Transporter Room 3@startrek.website
        333·
        1 year ago

        Any other day I’d see this get laughs, but I guess people are bitchier this time of day.

        I’d write down the ISO timecode I’m talking about, but I can’t afford it.

  • rtxn@lemmy.worldEnglish
    751·
    1 year ago

    You’ve just become the nemesis of the entire unix-like userbase for praising the space.

      • rtxn@lemmy.worldEnglish
        45·
        1 year ago

        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.

        • silly goose meekah@lemmy.world
          51·
          1 year ago

          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

          • rtxn@lemmy.worldEnglish
            21·
            1 year ago
            rsync -a "somedir" "somedir_backup_$(date)"

            If the date command returns an RFC-3339-formatted string, the filename will contain a space. If, for example, you want to iterate over the files using for d in $(find...) and forget to set $IFS properly, it can cause issues.

            • lolcatnip@reddthat.comEnglish
              2·
              1 year ago

              But $(date) does return a string with spaces, at least on every system I’ve ever used. And what’s so bad about the possibility of spaces in filenames? They’re slightly inconvenient in a command line, but I haven’t used a commuter this century that didn’t support spaces in filenames.

              • rtxn@lemmy.worldEnglish
                4·
                1 year ago

                Bro, literally re-read the comment you replied to. It has an example of what might happen.

                • lolcatnip@reddthat.comEnglish
                  1·
                  1 year ago

                  Ok, I just reread it. I don’t see what you think I’m missing. You mean an improperly written find command misbehaving? The fact that a different date format could prevent a bug from manifesting doesn’t seem like much of an argument.

            • calcopiritus@lemmy.world
              1·
              1 year ago

              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.

              • rtxn@lemmy.worldEnglish
                1·
                1 year ago

                For the rsync command, yes. But this:

                for d in $(find . -type d); do
    echo "$d"
done

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

    • Knusper@feddit.de
      4·
      1 year ago

      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.

    • CallumWells@lemmy.mlEnglish
      4·
      1 year ago

      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

      • hyperhopper@lemmy.world
        12·
        1 year ago

        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.

  • TeckFire@lemmy.worldEnglish
    42·
    1 year ago

    The difference:

    2023-12-12T21:18Z is ISO 8601 format

    2023-12-12 21:18 is RFC 3339 Format

    A small change

    • treadfulEnglish
      26·
      1 year ago

      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.

      • TeckFire@lemmy.worldEnglish
        10·
        1 year ago

        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.

        • Kogasa@programming.dev
          12·
          1 year ago

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

            • Kogasa@programming.dev
              1·
              1 year ago

              Thanks for the link. Reading it gave me a headache. Not because of the proposal, but because of the very clear explanation it includes of just how annoying time zones are. I never even thought about the fact that a time relative to a UTC timestamp isn’t uniquely associated with another UTC timestamp because the local UTC offset can change. It’s obvious when you say it, but now I’m wondering if I have more time zone bugs somewhere.

              • pixelscript@lemmy.mlEnglish
                2·
                1 year ago

                It only just hit me a month or two ago just what a timezone, as described by IANA, actually is.

                I’m from the eastern half of the US state of North Dakota. We run on what we’d collloquially call “central time”, often abbreviated CST. That’s UTC-6:00 in winter and UTC-5:00 in summer (technically CDT, but whatever).

                Long ago I had it passed down to me from on high that the IANA timezone indicator I should use for my local time is America/Chicago. Ok. Easy enough. Why Chicago, though? I long guessed because it happens to be one of the largest localities in the CST block? That is in fact the answer if you read the rationale of the tz database, but I did not know this at the time.

                What threw me off, though, is that there are other localities that seemingly map to the same time zone block. Like America/Mexico_City, or America/Indianapolis. What’s up with those? When I set my computer system clock to them, they behave just like America/Chicago does. Why are these here? And why these cities, specifically?

                Then, imagine the loop I was thrown for when I discovered three timezone definitions exclusive to North Dakota. Those being America/North_Dakota/Beulah, ../../Center, and ../../New_Salem. What the fuck…?? These are literal nowhere towns. Midwest America is the middle of nowhere. North Dakota is the middle of nowhere within the Midwest. And these three towns are the middle of nowhere to the rest of us in North Dakota. What is going on? Why are there three tiny timezones in the middle of nowhere in the middle of nowhere in the middle of nowhere? And they’re all right next to each other!

                Then, it clicked. What do these three places have in common? These towns all used to be in the next timezone over (“Mountain Time”, MST), but later decided to jump over to CST.

                There’s a humorous story for why this happened. Supposedly, drinkers in the capital city, Bismarck, would stay to bar close. Then, they’d all hop in their cars and drunk drive to the sister city across the river, Mandan, for an extra hour of fun, causing untold chaos in the process. The jump was allegedly to curb this. Sadly, that story apocryphal. In reality, it was just because it was economically favorable to be time-aligned with the state capital city. But I digress…

                If you were, say, looking over historic records of events recorded in both Bismarck and Beulah, where records are always taken simultaneously, and your data happened to span back before this switchover, there would be an inexplicable point in time where after it the timestamps would match, but before it, they’d be offset. So, to encode that, Beulah gets its own unique timezone all to itself that indicates this historical switchover exists.

                It also explains why there are three tiny timezones all right next to one another. Three counties participated in this switchover, and to make it happen, each one had to individually pass laws to enact it. These laws all took effect on slightly different dates. Thus, if we wish to capture the nuanced time shifts in all three counties, each county needs its own bespoke timezone.

                IANA timezones aren’t just representations of all the time zones that currently exist. They are representations of every unique permutation of historic clock changes for every place on Earth. That’s fucking nuts! Knowing that, I went from being shocked that there are so many timezones to being shocked that the list of timezones is as short as it is!

          • TeckFire@lemmy.worldEnglish
            2·
            1 year ago

            IMO, ISO 8601 is better for computers, people working with multiple time zones, or critical logging.

            RFC 3339 is better used colloquially, while still remaining unambiguous for the use cases that most people use dates and times in.

            • Kogasa@programming.dev
              4·
              1 year ago

              I’d rather have an explicit time zone any time a datetime is being passed around code as a string. Communicating it to a human is relatively safe since even if there’s a mistake, it’s directly visible. Before that last step, incorrect time zone parsing or implicit time zone assumptions in code that was written by “who knows” in the year “who knows” can be really annoying.

    • hyperhopper@lemmy.world
      83·
      1 year ago

      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.

      • elauso@feddit.de
        181·
        1 year ago

        But there is a separator between the numbers: the same one that also very reliably separates the words in this comment

        • hyperhopper@lemmy.world
          1·
          1 year ago
          1. A single separator is better than a choice of separators to mean the same thing.
          2. A space is not as apparent in a large log of data as a capital T
          3. 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.
  • kingthrillgore@lemmy.ml
    38·
    1 year ago

    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.

    • Mubelotix@jlai.lu
      241·
      1 year ago

      You HAVE to read the spec if you want to be compliant, you can’t just hope every detail is on wikipedia

    • K4mpfie@feddit.de
      8·
      1 year ago

      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

      • SirQuackTheDuck@lemmy.world
        81·
        1 year ago

        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.

  • Anna@lemmy.ml
    323·
    1 year ago

    Yeah I like a girl who is firm on her choice of date time format…😂😂😂😂

    • flambonkscious@sh.itjust.worksEnglish
      111·
      1 year ago

      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)

      • zik@lemmy.world
        21·
        1 year ago

        Both ISO8601 and RFC3339 are YYYY-MM-DD. The difference is in how the date and time are separated.

        • somenonewho@feddit.de
          1·
          1 year ago

          That’s a certain kind of skill I wouldn’t want the need to have. I just copy paste those timestamps into a terminal with date -d @ (and always forget the right syntax for that :D)

    • Dr. Dabbles@lemmy.worldEnglish
      9·
      1 year ago

      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.

      • Pratai@lemmy.world
        1·
        1 year ago

        Yeah… I have no idea what any of that means either. I’m sorry I caused you to write all that out.

  • CetaceanNeeded@lemmy.world
    111·
    1 year ago

    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.

    • sushibowl@feddit.nl
      71·
      1 year ago

      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.

  • r00ty@kbin.life
    4·
    1 year ago

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