How is day smaller than month? There are up to 12 values for month, but up to 31 for days
It’s sorted by the length of time, so a day is shorter than a month.
I use ss/mm/hh/dd/MM/YYYY
t.european
finally a correct version of this diagram
I work with international clients and use 2025-01-26 format. Without it… confusion.
That’s an ISO date, and it’s gorgeous. It’s the only way I’ll accept working with dates and timezones, though I’ll make am exception for end-user facing output, and format it according to locale if I’m positive they’re not going to feed into some other app.
“Europe”, as if there weren’t several languages in Europe with different date formats per language…
None of which start with the month because that would be fuckin stupid
Meh. It’s getting a lot of hate here, but I think it works well in casual short term planning. Context (July) - > precision (15).
If I want to communicate the day in the current month, I just say the day, no month.
ok but by that logic you’d start with the year
No because the year is a super large time; there’s a reason people always say they take a bit to adjust to writing the new year in dates because it’s s long enough period of time that it almost becomes automatic.
For archiving, sure; most other things, no (logically, ISO-8601 is probably the best for most cases, in general, but I’ll die on the hill that MM-DD-YYYY is better than DD-MM-YYYY).
the year is a super large time
Not when you’re old… I’ll be 50 this year, they’re flying by.
well either you omit the year, or you start with it
americans start with the month and end with the year, which is totally wild
well either you omit the year, or you start with it
Why? Because you say so?
Because it’s consistent that way. Why not is the real question?
Again, – within most use cases – it really isn’t.
In your day to day, will you need to know the year of a thing? Probably not; it’s probably with the year you’re currently in.
Do you need to know the day of the month first? Probably not unless it’s within the current month so you need to know the month first.
Telling me “22nd” on a paper means nothing if I don’t know what month we’re referring to; and, if I do need to know the year, – well – it’s always at the the of the date so it’s easy to locate rather than parsing the middle of the date, any.
In your day to day, will you need to know the year of a thing? Probably not; it’s probably with the year you’re currently in.
that’s why I said you could omit it. did you read what I wrote?
Everyone starts sentences with a capital letter, you shouldn’t be flinging shit mate 😂
nahh f that shit
Exactly. It would be like reading the minute of the clock before the hour.
*15th
I don’t know why anyone would ever argue against this. Least precise to most precise. Like every other number we use.
(I don’t know if this is true for EVERY numerical measure, but I’m sure someone will let me know of one that doesn’t)
They are all equally prescise. American one is stupid just like their stupid ass imperial units. European one is two systems slapped together(since they are rarely used together and when they are its the iso format) and iso is what european standard should be.
You misunderstand my comment.
I’m saying the digits in a date should be printed in an order dictated by which units give the most precision.
A year is the least precise, a month is the next least, followed by day, hour, minute, second, millisecond.
Sorting with either the month or the day ahead of the year results in more immediately relevant identifiable information being displayed first. The year doesn’t change very often, so it’s not something you necessarily need to scan past for every entry. The hour changes so frequently as to be irrelevant in many cases. Both the month and the day represent a more useful range of time that you might want to see immediately.
Personally, I find the month first to be more practical because it tells you how relatively recent something is on a scale that actually lasts a while. Going day first means if you’ve got files sorted this way you’re going to have days of the month listed more prominently than months themselves, so the first of January through the first of December will all be closer together then the first and second of January in your list. Impractical.
Year first makes sense if you’re keeping a list around for multiple years, but the application there is less useful in the short term. It’s probably simpler to just have individual folders for years and then also tack it on after days to make sure it’s not missing.
Also, like, this format is how physical calendars work assuming you don’t have a whole stack of them sitting in front of you.
All my homies hate ISO, RFC 3339 for the win.
All my homies hate ISO
Said no-one ever?
EDIT: thanks for informing me i now retract my position
Nah, ISO is a shit organization. The biggest issue is that all of their “standards” are blocked behind paywalls and can’t be shared. This creates problems for open source projects that want to implement it because it inherently limits how many people are actually able to look at the standard. Compare to RFC, which always has been free. And not only that, it also has most of the standards that the internet is built upon (like HTTP and TCP, just to name a few).
Besides that, they happily looked away when members were openly taking bribes from Microsoft during the standardization of OOXML.
In any case, ISO-8601 is a garbage standard.
P1Yis a valid ISO-8601 string. Good luck figuring out what that means. Here’s a more comprehensive page demonstrating just how stupid ISO-8601 is: https://github.com/IJMacD/rfc3339-iso8601P1Y is period notation. It means a Period of 1 Year. It actually makes decent sense tbh.
Sure, it means something, and the meaning is not stupid. But since it is the same standard, it should be possible to be used to at least somehow represent the same data. Which it doesn’t.
I think it is reasonable to say: “for all representation of times (points in time, intervals and sets of points or intervals etc) we follow the same standard”.
The alternative would be using one standard for points in time, another for intervals, another for time differences, another for changes to a timezone, another for …
The alternative would be
More reasonable, if you ask me. At least I came to value modularity in programming, maybe with standards it doesn’t work as good, but I don’t see why
Standards are used to increase interoperability between systems. The more different standards a single system needs the harder it is to interface with other systems. If you have to define a list of 50 standard you use, chances are the other system uses a different standard for at least one of them. Much easier if you rely on only a handful instead
if i am not wrong, it is because essentially both are same (slight differences in what is allowed and what is not, https://github.com/IJMacD/rfc3339-iso8601), but RFC is more free as in freedom
Thx i take that back
i never saw year first in Europe.
You’re reading the post backwards.
MM ≠ MM !!!
My stupid ass read this top to bottom and I was confused why anyone would start with seconds
Mmm US military date and time is fun too.
DDMMMYYYYHHMM and time zone identifier. So 26JAN20251841Z.
So much fun.
So virtually human unreadable and the letters make machine readability a pain in the ass?
As my friend used to say, there’s dumb and then there’s Army Dumb.
Honestly look very readable to me, though I’m not sure on the timezone bit. Maybe they left it out? Ohterwise it’s 26th of January 2025, 18:41
It’s gonna be problematic when there’s 5 digit years, but other than that it’s… not good, but definitely less ambiguous than any “normally formatted” date where DD <= 12. Is it MM/DD or DD/MM? We’ll never fucking know!
Of course, YYYY-MM-DD is still the king because it’s both human readable and sortable as a regular string without converting it into a datetime object or anything.
All you’d have to do to make it much more readable is separate the time and the year with some kind of separator like a hyphen, slash or dot. Also “Z” is the time zone, denoting UTC (see also military time zones)
Oh, duh. It’s why all my timestamps have Z’s in the database lmao
Thing is, you’re right that the separation would help, but this is still way less ambiguous that MM/DD vs DD/MM if you ask me.
YYYY.MM.DD HH.MM.SS, as eru ilúvatar intended
YYYY-MM-DD HH:MM:SS
Ftfy
I think I went to high school with that guy.
This pyramid visualisation doesn’t work for me, unless you read time starting with seconds.
A pyramid is built bottom to top, not top to bottom. That’s also one of the strengths of the ISO format. You can add/remove layers for arbitrary granularity and still have a valid date.
Yeah, but people read top to bottom. The best way to do it would be to have upside down pyramids. With the biggest blocks at the top representing the biggest unit of time (YYYY) and the smallest blocks at the bottom representing seconds & smaller.
Offene Feldschlacht betritt den Raum
2025-01-26-11-40-20
I get it, just pyramids are misleading, also year-month-day is better because resulting number always grows. 😺
A bit out of context, but is your username and instance a reference to nescafe?
Not really but now that you mentioned it, it will! 😄
That’s an interesting coincidence
2025-01-26T11:40:20, you mean?
Hold on there pal that time zone is ambiguous. Did you mean 11:40:20 UTC? If so, don’t forget your Z!
I mean 11:40:20 in what NodaTime would call a “LocalDateTime”. i.e., irrespective of the time zone.
(And incidentally, if you’re working in C# I strongly recommend the NodaTime library. And even if you’re not, I strongly recommend watching the lectures about dates and times by the NodaTime developer, who demonstrates a way of thinking about dates and times that is so much more thoughtful than what most standard libraries allow for without very careful attention paid by the programmer.)
Yeah
I’m almost 40 and now just realizing my insistence on how to structure all my folders and notes is actually an ISO standard. Way to go me.
I stumbled upon it years ago because sorting by name sorts by date. There was no other thought put into it.
It’s incredibly annoying that in clinical research we are prohibited from using it because every date must comply with the GCP format (DD mmm yyyy). Every file has the GCP date appended to the end.
Hot take: 2025-Jan-27 is better than 2025-01-27 in monolingual contexts.
The beautiful part of 2025/01/27 is that it can inherently be sorted without formatting.
