Migrate to ISO 8601 date format

[jonatan-ivanov]

ISO 8601 is the international standard for date (and time). I'm not sure if I need to advocate for it in this repo but I offer my help to do the migration in a PR. Please let me know if you are interested and I can create a PR.

[bmvermeer]

I am in favor of standards, but what are you suggesting?
Rebuilding that the output (HTML) is ISO 8601, or the JSON or the input. or all of it.

Currently an addition is just adding a line in in the Readme (so super low bar), if we want to enforce standards, there needs to be some automation around this to verify or adjust where needed.

Happy to discus what you have in mind.

[jonatan-ivanov]

I would change all for sake of consistency (readme, html, json).
I guess there is no date formatting right now, it's just free text, so once the readme is migrated, the rest will be too?

I think the current way of adding a line can stay the same: people will use the date format that is already there but PRs can be validated with a GH workflow.

[rmannibucau]

makes sense for json, please keep the rest human readable so not ISO8601

[jonatan-ivanov]

ISO 8601 meant to be human readable:

Representations can be done in one of two formats – a basic format with a minimal number of separators or an extended format with separators added to enhance human readability.

2009-01-06 is the extended format, it seems very human readable to me.

Edit: another (might be overlooked) angle: there are many languages that don't "name" months, if you literally translate their months to english, the name of the month is 1st month, 2nd month, etc. They might need to do extra mental gymnastics to translate "August" (or "Aug" to the 8th month) but neither them nor people who speak languages that "name" months usually need extra mental gymnastics to see which month is 2025-09-22 in I guess.
I'm biased since I only speak languages that "name" their months and they are also very similar to the english name, but there are a lot of people who speak languages natively that don't. This is not about the translation, this is about how your brain is wired but maybe people who actually natively speak these languages can give you better feedback about readability of ISO 8601 vs. spelling out the date.

[noctarius]

I'm also a big fan of 8601. Mainly because it rules out misinterpretation of day and month 01/05/2025 and 05/01/2025.

As long as month names are used, it's not much of a big deal, but for number-based dates, iso 8601 is just cleaner to understand and actually fully sortable :)

[rmannibucau]

ISO 8601 meant to be human readable

But it is not, it is 100% an interexchange format which is intended to be usable by machine (your short example is sortable for ex).
Nobody on the human beings side puts the year first for ex and in the context of this app it doesn't make sense since we already group by year.

"month-day" or "day-month" is ambiguous ver the world so best you can do is to put some letters there IMHO - for human side, for JSON no discussion.

Something like 01 Jan. or alike is the less ambiguous for everybody until you want to use moment to translate it to the browser locale for ex.

[jonatan-ivanov]

But it is not, it is 100% an interexchange format which is intended to be usable by machine (your short example is sortable for ex).

The ISO 8601 definition literally says that the extended format was added to enhance human readability, the basic format is more compact and it is for machines. Also, I'm not sure how the format being sortable excludes its readability.

Nobody on the human beings side puts the year first for ex

I think this is the point when I should stop arguing with you. How wrong I was when I thought I don't need to advocate for ISO 8601 here. :D But I don't argue with beliefs, there is no point doing it. I just want to leave here that the following countries do put the year first (YMD): China, Japan, South Korea, Taiwan, Hungary, Mongolia, Lithuania, Bhutan
And there are many other countries that sometimes put the year first (and sometimes they don't).

in the context of this app it doesn't make sense since we already group by year.

I don't think that excludes anything. Your following arguments btw exactly why ISO 8601 was created. It is unambiguous and it is equally human readable for everyone.

[bmvermeer]

@jonatan-ivanov
As long as the output on the website and the readme is human readable I am all up for it and so is Christoph so I see.
I am personally all up for consistency so no point there.
The only thing that hold me back before was that we do date ranges now in short hand form (eg 22-24 Sept) so I am curious how you want to solve this.

Feel free to submit a pull request and I will be happy to work on it. Thanks for bringing this up because essentially we agree and I appreciate the help :)

[rmannibucau]

literally says that the extended format was added to enhance human readability

enhance doesn't mean it reaches human readability.
as a matter of fact there are several human standard format (and even several per country/language) but none uses iso8601 so it is literally done fo rmachine with the intent to ease human interaction but it can't be by design

I'm not sure how the format being sortable excludes its readability

Not strictly excludes but reduces for the mentionned reason.

China, Japan, South Korea, Taiwan, Hungary, Mongolia, Lithuania, Bhutan

You're right but it covers very few of the content of the repo which is mainly US/EU in terms of audience.

It is unambiguous and it is equally human readable for everyone.

This is right - and why I do always use it in JSON API - but equally bad doesn't mean it is a good choice.

The other point where using an unambiguous date (12 Jan. for ex) is that the site is in english so focusing on the important part and not starting by a lower important part (the year in current layout) is better for users IMHO.

[jonatan-ivanov]

For the date ranges, there are quite a few options:

• ISO 8601 has standardized date ranges, for example Devnexus (4-6 March 2026) can be any of these:

2026-03-04--2026-03-06
2026-03-04/2026-03-06
2026-03-04--03-06
2026-03-04/03-06
2026-03-04--06
2026-03-04/06

• Spelling out two ISO 8601 dates is also an option: 2026-03-04 - 2026-03-06
• Or having different columns for start and end dates (in the json they would be separate fields and this needs a bit more work updating the render script), this can be also applied for cfp open/close dates
• I would also play with the idea of not having an end date and only have the start date of a conference (regardless of the ISO 8601 change)