ISO8601

260 readers
1 users here now

Community dedicated to the international standard YYYY-MM-DD date format.

founded 2 years ago
MODERATORS
1
153
submitted 4 months ago* (last edited 4 months ago) by Redjard@lemmy.dbzer0.com to c/iso8601
 
 

Some years ago in a chain of discussion the more typical simple pyramid representation of date formats was improved to incorporate every (big and) little detail of the various formats accurately.

The annotated regions of usage are debated however.

The first insight is that numbers themselves are ordered most to least significant, that's why every numeric element is sloped top to bottom. This shows why dd.mm.yyyy is not well-ordered, even ignoring the time component.

Then, am/pm is actually its own segment of the time notation when it is used, and as the biggest is misplaced when put after time.
Put between date and time it is still inefficient, but at least placed in order (and is alphabetically sorted).

Another neat detail is the quirk of 12h time to call the first hour 12 instead of 00. This is represented by the lowest section of the hour bar spiking to be the widest.

One remaining inaccuracy is that the width of the bars does not match their encoded amount of information. It would be sensible to have the day be 5x wider than am/pm, and the (4 digit) years 2.6x as wide as the days, but alas that would be too impractical for such a well-designed infographic.

I inverted the original because I prefer darkmode. Here is the originalI cast retinal damage

2
 
 
3
112
ISO 8601 ftw rule (gregtech.eu)
submitted 1 year ago by lambalicious to c/iso8601
 
 

publicado de forma cruzada desde: https://gregtech.eu/post/6514020

!iso8601@lemmy.sdf.org gang, rise up

4
 
 

Because he didn't know about ISO8601. The only correct date format, especially in Canada.

5
 
 

RFC 3339, the "alternative" to ISO 8061, was extended to RFC 9957, which also allows adding interpretative tags.

Sounds like unnecessary complexification to me. What is wrong if anything with "2024-04-26"?

6
 
 

While not strictly ISO 8601, it's closely related. RFC 3339 was/is basically a subset of ISO 8601, allowing only what's strictly "needed" or really universal: e.g. 2024-05-27, 2024-03-13 12:34:56Z, etc., nothing like 2018-W06-1 or 2018-036.
Now what's really interesting is how additional data for timestamps was added. For example, specifying the human-readable timezone name, instead of just the UTC offset: 2022-07-08T00:14:07Z[Europe/Paris].

7
 
 
8
 
 

publicado de forma cruzada desde: https://lemmy.world/post/9470764

  • ISO 8601 is paywalled
  • RFC allows a space instead of a T (e.g. 2020-12-09 16:09:...) which is nicer to read.
9
 
 

I've seen the Wikipedia article on year 9 doesn't mention anything of relevance happening during November. Closest thing seems to be September. Since people around have spent a few years making lots of ruckus about how the date with "9, 11" has some sort of importance as a date, I was wondering if I'm missing something here.

10
 
 

Basically title. 2019 edition of the Standard denotes the "T" prefix to time as mandatory (except in "unambiguous contexts"):

01:29:59 is now actually T01:29:59, with the former form now designated as an alternative

But date does not have a "D" prefix, not even in "ambiguous contexts".

1973-09-11 never needs to be something like eg.: D1973-09-11

Anyone know the reasoning behind this change and what is the intended use? The only time-only format with separators that I can think would be undecidable in ambiguous contexts would be hh:mm which I guess could be mistaken for bible verses?

11
 
 

I mean, it's the obvious choice. So why not? Maybe we can do with the zoom on the cat if there is a better version.