ISO8601

201 readers
33 users here now

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

founded 2 years ago
MODERATORS
[email protected]
listing: all - local
1
23
[email protected] (World News) community doesn't use ISO8601 (lemmy.world)
submitted 1 day ago by [email protected] to c/[email protected]
7 comments fedilink
 
 
2
108
ISO 8601 ftw rule (gregtech.eu)
submitted 1 month ago by [email protected] to c/[email protected]
19 comments fedilink
 
 

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

[email protected] gang, rise up

3
246
Canadian man reading date never knows which is day and which is month unless day is above 12 (thebeaverton.com)
submitted 5 months ago by [email protected] to c/[email protected]
29 comments fedilink
 
 

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

4
3
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information (datatracker.ietf.org)
submitted 7 months ago by [email protected] to c/[email protected]
2 comments fedilink
 
 

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"?

5
4
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information (datatracker.ietf.org)
submitted 10 months ago by [email protected] to c/[email protected]
0 comments fedilink
 
 

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

6
14
Just found the worst time/date format (sh.itjust.works)
submitted 1 year ago by [email protected] to c/[email protected]
2 comments fedilink
 
 
7
15
Standards shouldn't be behind a paywall (lemmy.world)
submitted 1 year ago by [email protected] to c/[email protected]
1 comments fedilink
 
 

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.
8
5
Anything of interest happen in 9-11? (en.wikipedia.org)
submitted 2 years ago by [email protected] to c/[email protected]
0 comments fedilink
 
 

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.

9
3
What is the need of T in the new (2019) time format? (lemmy.sdf.org)
submitted 2 years ago by [email protected] to c/[email protected]
1 comments fedilink
 
 

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?

10
6
2023-08-13: Kindly proposing a logo / banner for this community (xkcd.com)
submitted 2 years ago by [email protected] to c/[email protected]
1 comments fedilink
 
 

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.