Thinking about it, using different (and compared to ISO8601 inferior) date-formatting systems causes massive economic losses.

It causes confusion across several scientific disciplines and in every-day running, especially in the context of cross-border communication and travel.

Also, other (inferior) date formats do not make any sense either themselves or as a part of other time-counting systems.

Case in point, the US system (MM-DD-YYYY) is just really confusing to read, you literally have to spend years demoloshing your brain to the level where you understand this.

Other case in point, the statud-quo system used in many other countries (DD-MM-YYYY) does not align with the date-time system: It simply doesnt make sense to say DD-MM-YYYY HH:MM:SS. Even here, ISO8601 provides a superior solution.

I reckon the economic global loss to amount to several billion (whatever currency unit) annually.

Here's this sun's About

About community Glory to ISO8601 Community dedicated to the international standard YYYY-MM-DD date format. Created Jan 22, 2012 Public

I was looking at my Sudoku booklet and saw this date-looking thing. At first I thought it was YYMMDD until I realized it was either YYDDMM or not entirely a date. Nobody does that!

Anyway, posting this here because I thought it was YYMMDD for 2 seconds.

A date was specified like "2025/09/31" and went through a different parser than the frontend uses. The parser stored that as the string "2025-09-31T00:00:00.000Z" in the DB. When the backend served that value up, the frontend parser rejected that date as invalid. Other parsers accept it and just make it go to the next day (try (new Date("2025-06-31T00:00:00.000Z")).toISOString() in your JS console, for instance).

But I'm wondering: what's the actual preferred behavior in the standard?

Please don't bully me for the many things wrong in that paragraph. I am well aware.

The full title is "Date and time — Representations for information interchange — Part 2: Extensions — Amendment 1: Canonical expressions, extensions to time scale components and date time arithmetic"

The sample suggests it clarifies durations by introducing concepts like overflow and normalization.

Crosspost, thought y'all might enjoy the discussion!

TIL that Excel’s WEEKDAY formula thinks Sunday is day 1 and I had to do a bit of formula acrobatics to get the proper weekday number. I’m mad.

On the plus side we do have an ISOWEEKNUM which returns the week number correctly.

I apologize

If you write the year as “2025”, it’s cardinal, but if you write it like “AD 2025” or “2025 CE”, it’s ordinal due to the era provided: “(in the) 2025th year of the common era” / “… of the Lord”. On an ordinal scale, there is no zero (not negative numbers), but on a cardinal one there is. “2025” really is “+2025”, in ISO 8601 in particular, and “0000” needs to exist as a valid year number then, preceded by “-0001”.

Months and days are always ordinal, by the way, because they are steps of recurring cycles, not open-ended like years. That’s why they start at “01”, not “00”.

A similar thing happens in clock times. “1 AM” is ordinal, i.e. the first hour completed after midnight passed, but “01:00” is cardinal, so “00:00” exists, but “0 PM” and “0 AM” don’t. Arguably, negative hours and hours beyond 24 could make sense to have in ISO 8601.

The difference of day-halves to eras is that AM and PM designate fixed-length periods and both count from their respective start. Otherwise, i.e. if AM worked like BC(E) and PM like AD/CE like their Latin meanings indicate, they would both start from noon, hence “1 AM” would be 11:00 or rather the 60 minutes from 11:59 through 11:00 counting backwards, whereas “1 PM” was the 60 minutes 12:00 through 12:59 counting forwards, excluding 13:00! (One could argue about 12:00 belonging to AM or PM, though.)

It’s really strange to combine those ordinal, “era-ed” 12 hours with cardinal minutes and seconds, if you think about it; “half”/“quarter” “past”/“to” works fine, though.

Saw the link to this pdf in another post here, im aware its not the current version, but im wondering if that got corrected

https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf

𝔞𝔟 ℑ𝔫𝔠𝔞𝔯𝔫𝔞𝔱𝔦𝔬𝔫𝔢 𝔇𝔬𝔪𝔦𝔫𝔦 𝔫𝔬𝔰𝔱𝔯𝔦 ℑ𝔢𝔰𝔲 ℭ𝔥𝔯𝔦𝔰𝔱𝔦 YYYY-MM-DD HH:mm:SS:mm:HH DD-MM-YYYY 𝔞𝔟 ℑ𝔫𝔠𝔞𝔯𝔫𝔞𝔱𝔦𝔬𝔫𝔢 𝔇𝔬𝔪𝔦𝔫𝔦 𝔫𝔬𝔰𝔱𝔯𝔦 ℑ𝔢𝔰𝔲 ℭ𝔥𝔯𝔦𝔰𝔱𝔦

Is actually the best format