ISO8601
- • 97%thebeaverton.com Canadian man reading date never knows which is day and which is month unless day is above 12
KITCHENER – Local man Dalton Strickland, whose data entry job regularly requires him to read dates off a form and put them into a computer, literally never knows which date is the day and which is the month unless the day is above 12. “Are we using the American MM-DD-YYYY system or the rest of […]
Because he didn't know about ISO8601. The only correct date format, especially in Canada.
- • 100%datatracker.ietf.org RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
This document defines an extension to the timestamp format defined in RFC 3339 for representing additional information, including a time zone. It updates RFC 3339 in the specific interpretation of the local offset , which is no longer understood to "imply that UTC is the preferred reference point fo...
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"?
- • 100%datatracker.ietf.org RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
This document defines an extension to the timestamp format defined in RFC 3339 for representing additional information, including a time zone. It updates RFC 3339 in the specific interpretation of the local offset , which is no longer understood to "imply that UTC is the preferred reference point fo...
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].
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.
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.
Basically title. 2019 edition of the Standard denotes the "T" prefix to time as mandatory (except in "unambiguous contexts"):
01:29:59is now actuallyT01:29:59, with the former form now designated as an alternativeBut date does not have a "D" prefix, not even in "ambiguous contexts".
1973-09-11never needs to be something like eg.:D1973-09-11Anyone 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:mmwhich I guess could be mistaken for bible verses?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.
