There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.

The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.

I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.

  • mox@lemmy.sdf.org
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    2 years ago

    ISO 8601 date format. Not because it’s from a standards body, but because it’s simple, sensible, clearly defined, easy to recognize, and very effective.

    Date field placement in any order other than most-significant-digits-first is not only counterintuitive, but needlessly complicated to work with. Omitting critical information like the century is ambiguous and confusing.

    We don’t live in isolated villages any more. Mixing and matching those problems by accepting all the world’s various regional and personal date styles, especially with no reliable indication of which ones apply in any given case, leads to the hodgepodge of error-prone date madness that we have today.

    The 2024-09-02 format should be taught in schools and required in official documents. Let the antiquated date styles fall into disuse outside of art and personal correspondence, like cursive writing.

    • pHr34kY@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      2 years ago

      I love this standard. If you dig deeper into it, the standard also covers a way to express intervals and periods. E.g. “P1Y2M10DT2H30M” represents one year, 2 months, 10 days, 2 hours and 30 mins.

      I recall once using the standard when writing a cron-style scheduler.

      I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.

      Also: Does Excel recognise a full ISO8601 timestamp yet?

      • Jim@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 years ago

        I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.

        I’ve seen bugs where programmers tried to represent date in epoch time in seconds or milliseconds in json. So something like “pay date” would be presented by a timestamp, and would get off-by-one errors because whatever time library the programmer was using would do time zone conversions on a timestamp then truncate the date portion.

        If the programmer used ISO 8601 style formatting, I don’t think they would have included the timepart and the bug could have been avoided.

        Use dates when you need dates and timestamps when you need timestamps!

        • cout970@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          2 years ago

          Thats an issue with the time library, not with timestamps. Actually timestamps are always in UTC, you need to do the conversion to your local time when displaying the value. There should be no possible off-by-one errors, unless you are doing something really wrong.

    • driving_crooner@lemmy.eco.br
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      I had the fortune of being hired to build up from zero my department, and one of the first “rules” I made was all dates are ISO-8601 and now every process runs with 8601, if you use anything different your code is going to fail eventually when it finds another column date in 8601.

    • MoonlightFox@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      And it can be sorted alphabetically in all software. That’s a pretty big advantage when handling files on a computer

    • The_Decryptor@aussie.zone
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      2 years ago

      RFC 3339 is a simplified profile of 8601 that only covers YYYY-MM-DD style formatting, if you only ever use that format and avoid the things like “2024-W36” they’re mostly interchangeable.

      • The week-of-year is far more relevant in Western Europe, and is used quite a bit in business. I have a Junghans watch that has a week complication.

        It’s an important format outside of the US, and gives ISO-8601 an edge as a standard of conformance.

  • Bora M. Alper@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 years ago

    ActivityPub :) People spend an incredible amount of time on social media—whether it be Facebook, Instagram, Twitter/X, TikTok, and YouTube—so it’d be nice to liberate that.

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    2 years ago

    I wish standards were always open access. Not behind a 600 dollar paywall.

    When it is paywalled I’m irritated it’s even called a standard.

  • webbureaucrat@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    I’ll give my usual contribution to RSS feed discourse, which is that, news flash! RSS feeds support video!

    It drives me crazy when podcasters are like, “thanks for listening to our audio podcasts. We also have a video feed for our YouTube subscribers.” Just let me have the video in PocketCasts please!

  • pHr34kY@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 years ago

    IPv6. Stop engineering IoT junk on single-stack IPv4, you dipshits.

    Ogg Opus. It’s superior to everything in every way. It’s free and there is absolutely no reason to not support it. It blows my mind that MPEG 1.0 Layer III is still so dominant.

  • filister@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 years ago

    The metric system, f*ck the imperial system. Every scientist sticks to the metric system, and why are people even still having an imperial system, with outdated measurements like stones for weight blows my mind.

    Also f*ck Fahrenheit, we have Celsius and Kalvin for that, we don’t need another hard to convert temperature measurement.

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 years ago

    TOML instead of YAML or JSON for configuration.

    YAML is complex and has security concerns most people are not aware of.

    JSON works, but the block quoting and indenting is a lot of noise for a simple category key value format.

    • FizzyOrange@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      2 years ago

      TOML is not a very good format IMO. It’s fine for very simple config structures, but as soon as you have any level of nesting at all it becomes an unobvious mess. Worse than YAML even.

      What is this even?

      [[fruits]]
      name = "apple"
      
      [fruits.physical]
      color = "red"
      shape = "round"
      
      [[fruits.varieties]]
      name = "red delicious"
      
      [[fruits.varieties]]
      name = "granny smith"
      
      [[fruits]]
      name = "banana"
      
      [[fruits.varieties]]
      name = "plantain"
      

      That’s an example from the docs, and I have literally no idea what structure it makes. Compare to the JSON which is far more obvious:

      {
        "fruits": [
          {
            "name": "apple",
            "physical": {
              "color": "red",
              "shape": "round"
            },
            "varieties": [
              { "name": "red delicious" },
              { "name": "granny smith" }
            ]
          },
          {
            "name": "banana",
            "varieties": [
              { "name": "plantain" }
            ]
          }
        ]
      }
      

      The fact that they have to explain the structure by showing you the corresponding JSON says a lot.

      JSON5 is much better IMO. Unfortunately it isn’t as popular and doesn’t have as much ecosystem support.