As for why it's better:

1. It's in sort order. Even if you use it for things that don't understand dates, they sort properly because the day is the last part, month is the middle part, and year is the first part. If you include hours, minutes or seconds, the sort order is still preserved.
2. Speaking of things that don't understand dates, because there are no slashes, you can easily use it in file names, directories, and anything else that treats slash as a special character. In addition, if you include the time part, because it uses "T" to separate the date and time, it doesn't use a space, so once again it can be easily used anywhere where a space might cause issues.

RFC 3339

This is the way.

ISO would be great, but sadly OmegaStar doesn't support ISO timestamps yet.

Except I can't get behind the time part of it, personally. I can see the point of doing GMT with the offset if you're working across multiple timezones, but it's overkill for situations where you aren't.

💯

Not shit enough for a shitpost.

Yep and it needs to use hyphens and not slashes. It helps avoid missed typos or mis-reads in some situations, especially if hand-written.

ISO 8601 my beloved

RFC3339 is better than ISO8601 since it doesn't allow some of the esoteric formats, and allows some useful formats that ISO8601 doesn't (like separating date and time by a space instead of by T)

For example, 2026-W32-1 is also a valid ISO8601 date: Monday on the 32nd week of 2026. That format isn't allowed with RFC3339.

https://ijmacd.github.io/rfc3339-iso8601/

I see the duality in this but I still think both are valid. When telling the time, there's usually no point in including the seconds since they'll have changed before you finish saying the whole thing anyway. In spoken word IMO it makes sense to go from more specific to less specific, and even not include extra parts sometimes (e. g. "today is the 3rd" when it's expected to know the month and, well, year from context, or "it's half past" to someone whom you've told the time a couple of minutes ago).

That’s really funny. DMY is more like Hms in that it is in descending order of relevance. Most people asking the date or time are looking for the hour of the day or the day of the month, and the rest is context.

The point is the order of importance, i am gonna need to know day and month we are in way more often than the year, i also want to know more often the hours and the minutes than the seconds, the seconds change way too often to be useful in most scenarios

Beat me to it, except I’d do yyyy-mm-dd because some OSes throw fits about having slashes in file names. Way better than the “Group Project-final FINAL v3 PAUL USE THIS ONE.file” versioning system that people seem to use.

nerd detected

HISSSSSS.

switch the slashes to dashes

[Angry ISO-8601 noises]

I should turn your comment into a shitpost...

There is for everything a

write the millennium between the month and century

That took me a minute to parse, but now I like it.

It’s not a bad idea to write it 6202 but then we’re redoing all the numbers, and that’s going to take time

Tis the Canadian way.

13 months of 4 weeks of 7 days. Add a holiday for new years that is not in any month. Call the 13th month Smarch to match the misprinted calendars.

The problem is not the format itself, its just sometimes we don't know which format is used: 07/07/26

Edit: This was probably a bad example, because it does not matter which format, as it is clear it is 7th of July 2026 in both possible formats. A better example: 01/02/26

RFC3339 is better than ISO8601 since it doesn't allow some of the esoteric formats, and allows some useful formats that ISO8601 doesn't (like separating date and time by a space instead of by T)

For example, 2026-W32-1 is also a valid ISO8601 date: Monday on the 32nd week of 2026. That format isn't allowed with RFC3339.

https://ijmacd.github.io/rfc3339-iso8601/