you are viewing a single comment's thread
view the rest of the comments
[–] 39 points 1 year ago (13 children)

RFC 3339 if you please. Let's be prescriptive.

  • source
  • parent
  • hideshow 13 child comments
  • [–] 15 points 1 year ago (8 children)

    After all the self-important blowhards in the committe were satisified that they had put their fingerprint on the ISO8601 document with bullshit like "year-month-week" format support and signed off, they went home.

    The rest stayed behind, waited a few minutes to be safe, and then quickly made RFC3339 like a proper standard.

    This is what RFC3339 vs ISO8601 feels like.

  • source
  • parent
  • hideshow 8 child comments
  • [–] 10 points 1 year ago* (2 children)

    Let's not forget that technically you have to pay for ISO8601, despite it being nearly useless as a standard because it allows several incompatible formats to coexist.

    Fucking wild.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 year ago (4 children)

    ISO8601 is YYYY-MM-DD nothing to do with weeks and isn;t the only difference of RFC3339 that you can use a space instead of a T in between the date and time? Also RFC3339 is only an internet standard while ISO is a generally international standard?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 1 year ago (1 child)
  • [–] 1 point 1 year ago

    Yeah I know, but it also has a different use case. As far as I know RFC3339 is mostly used for programming while ISO8601 is the standard for international communication and I wish people would use it more. I have processed American invoices in the wrong month because of their date structure. I have no reason to it, but I always write my date ISO 8601 (YYYY-MM-DD)

  • source
  • parent
  • [–] 3 points 1 year ago (1 child)

    No idea what you based those claims on, but the spec itself (I have the pdf) and Wikipedia's summary disagree. ISO8601 allows for YYY-MM-DD yes but it allows for a bunch of silly stuff.

    https://en.m.wikipedia.org/wiki/ISO_8601

    Both "2025-W24-4" and "2025‐163" are valid representations of today's date in ISO8601.

    (Also the optional timezone makes it utterly useless.)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago

    The omitting of timezones doesn't matter to a vast majority of the world, since most countries only have one time zone so I don't see a reason why that is relevant in most use cases.

    ISO is a general standard, it's in the name and the RFC is created for the internet, that is also in the name/description of the RF.

    Using 2025-164 can be handy, I actually use the day of the year to check what invoices from previous year are open since those are the invoices that are due 164 days or more.

  • source
  • parent
  • [–] 4 points 1 year ago (3 children)

    Anyone help enlighten me about whatever this and unix epoch are getting at? Are these really more specific/better than iso 8601 and why specifically?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 12 points 1 year ago* (last edited 1 year ago) (2 children)

    Happily!

    So, first epoch time. It's a pretty robust standard, covers many use cases, has few edge cases... but it's specifically for machine usage, since it's not human readable and it's not reversible into the past (pre-1970).

    ISO 8601 (depending on the annum), by the text of the documentation, these are all valid dates:

    • 2007-04-05T14:30
    • 2007-04-05T12:30−02:00
    • 2007-04-05T14:30Z
    • 200704051430
    • 07-04-05T14:30
    • 2007-95T14:30

    Etc.

    RFC 3339 (& RFC 9557, it's newest modification) is actually a subset of ISO 8601 and is far more prescriptive. For example you must have a timezone designator. You must have a separator between the date and time. You must use a dash between date elements and a colon between time elements. You can easily add standardized subseconds.

    • 2007-04-05T12:30−02:00
    • 2007-04-05 14:30Z

    This means that RFC 3339 is much easier to parse and use by both machines and humans.

    This page (reddit, I know...) has a great summary, and so in the interest of knowledge and attribution I'll link it: https://www.reddit.com/r/ISO8601/comments/p572xy/rfc_3339_versus_iso_8601/

    This website allows you to more directly compare the two interactively. https://ijmacd.github.io/rfc3339-iso8601/

  • source
  • parent
  • hideshow 2 child comments