"Europe", as if there weren't several languages in Europe with different date formats per language...
93
Mr_Blott @feddit.uk - 11mon
None of which start with the month because that would be fuckin stupid
96
htrayl - 11mon
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.
25
Mr_Blott @feddit.uk - 11mon
*15th
1
comtact @lemmy.world - 11mon
Keep that kinda talk up and you'll go straight to tariff!
1
nesc @lemmy.cafe - 11mon
This pyramid visualisation doesn't work for me, unless you read time starting with seconds.
56
Mirodir @discuss.tchncs.de - 11mon
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.
32
Zagorath - 11mon
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.
31
catexaminer @beehaw.org - 11mon
What do you think this is some sort of pyramid scheme?
3
itslilith - 11mon
Offene Feldschlacht betritt den Raum
3
Lena - 11mon
2025-01-26-11-40-20
17
nesc @lemmy.cafe - 11mon
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?
6
nesc @lemmy.cafe - 11mon
Not really but now that you mentioned it, it will! π
11
Lena - 11mon
That's an interesting coincidence
4
Zagorath - 11mon
2025-01-26T11:40:20, you mean?
17
olympicyes @lemmy.world - 11mon
Hold on there pal that time zone is ambiguous. Did you mean 11:40:20 UTC? If so, donβt forget your Z!
5
Zagorath - 11mon
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.)
1
Lena - 11mon
Yeah
2
lazynooblet - 11mon
I work with international clients and use 2025-01-26 format. Without it.. confusion.
54
ByteJunk @lemmy.world - 11mon
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.
32
czardestructo @lemmy.world - 11mon
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.
35
valkyre09 @lemmy.world - 11mon
I stumbled upon it years ago because sorting by name sorts by date. There was no other thought put into it.
16
clockworkrat(he/him) - 11mon
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.
10
Bo7a - 11mon
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)
34
Oniononon - 11mon
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.
10
Bo7a - 11mon
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.
13
millie @beehaw.org - 11mon
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.
2
Kacarott @aussie.zone - 11mon
By keeping years in different folders you are just implicitly creating the ISO format: eg. 2025/"04/28.xls"
2
millie @beehaw.org - 11mon
Well, not really. Sort of.
2025/"04-28-2025.xls"
You still want the year in the title format so you have it if it ends up on its own somewhere.
1
Umbrias @beehaw.org - 11mon
You are looking not for precision but for largest to smallest, descending order. this is distinct from precision, a measure of how finely measured something is. 2025.07397 is actually more precise than 2025/01/27, but is measured by the largest increment.
1
Bo7a - 11mon
And to address the argument on precision versus descending. I disagree. An instrument counting seconds is more precise than a machine counting minutes, hours, days, weeks, months etc... And that holds true through the chain. The precision is in the unit.
2
Umbrias @beehaw.org - 11mon
the unit is just a report of orientation, not magnitude. if you have a digital counter you are limited by the precision of the digital counter, not the units chosen. an analog measurement however is limited instead by other uncertanties. precision has, genuinely, no direct relationship to units. precision is a statistical concept, not a dimensional one.
1
Bo7a - 11mon
We can debate this all day. And I can't honestly say that I would take either side in a purely semantics argument.
But the wording comes directly from RFC3339 which is, to me, the definitive source for useful date representation.
If date and time components are ordered from least precise to most
precise, then a useful property is achieved. Assuming that the time
zones of the dates and times are the same (e.g., all in UTC),
expressed using the same string (e.g., all "Z" or all "+00:00"), and
all times have the same number of fractional second digits, then the
date and time strings may be sorted as strings (e.g., using the
strcmp() function in C) and a time-ordered sequence will result.
1
Umbrias @beehaw.org - 11mon
They chose poor words for this.
1
Kacarott @aussie.zone - 11mon
Largest to smallest is also wrong. In 2025/01/28, the 28 is larger than the 01.
It should be "most significant" to "least significant"
1
Umbrias @beehaw.org - 11mon
largest to smallest is correct. 1 mile is larger than 20 meters. if i had specified numerical value or somesuch, maybe you'd be correct. though significance works as well.
1
Kacarott @aussie.zone - 11mon
Largest to smallest is at best ambiguous. It can refer to the size of the number itself, or the size of the unit.
There is a reason this exact concept in maths/computer science is known as the "significance" of the digit. Eg. The "least significant bit" in binary is the last one.
1
Umbrias @beehaw.org - 11mon
significance refers to a measurement certainty about a number itself, especially its precision! and is unrelated to the magnitude/scale. the number and dimension "2.5634 mm" has more significant digits than the number "5,000 mm", though the most significant digit is 2 and 5 respectively, and least significant 4 and 5 respectively. this is true if i rewrite it as 0.0025634 m and 5 m. it does work for doing what you say in this case because a date is equivalent to a single number, but is not correct in other situations. that's why i said it does work here.
largest to smallest increment is completely adequate, and describes the actual goal here well. most things are ambiguous if you try hard enough.
1
istdaslol @feddit.org - 11mon
My stupid ass read this top to bottom and I was confused why anyone would start with seconds
26
Derpgon - 11mon
All my homies hate ISO, RFC 3339 for the win.
25
Amon - 11mon
All my homies hate ISO
Said no-one ever?
EDIT: thanks for informing me i now retract my position
21
namingthingsiseasy @programming.dev - 11mon
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).
In any case, ISO-8601 is a garbage standard. P1Y is 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-iso8601
P1Y is period notation. It means a Period of 1Year. It actually makes decent sense tbh.
5
Derpgon - 11mon
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.
3
groet @infosec.pub - 11mon
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 ...
1
lad - 11mon
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
4
groet @infosec.pub - 11mon
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
1
Derpgon - 11mon
True, that is reasonable. However sometimes it could be represented as scope creep. Depends on the thing, really. The more broad a standard is, the easier it is to deviate from given standard or not implement certain feature because there is not enough resources to do so.
I'd rather have multiple smaller standards than one big. However, I understand your reasoning.
1
sga @lemmings.world - 11mon
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
12
Amon - 11mon
Thx i take that back
4
ShareMySims @lemmy.dbzer0.com - 11mon
Maybe in programming or technical documentation, but no, when I check the date I want to know the day and the month, beyond that, it's all unnecessary information for everyday use, and we have it right in Europe.
You can't change my mind. Β―\_(γ)_/Β―
23
lurklurk @lemmy.world - 11mon
You canβt change my mind.
That's not a good thing. That attitude limits you from improving how you do things because you've gotten emotionally attached to some arbitrary ... never mind. Have a nice day.
8
WIZARD POPEπ« - 11mon
These people are just too far into the ISO rabbit hole. I completely agree with you that DD.MM.YYYY is the best format for everyday use.
5
HatchetHaro - 11mon
the "best" format for everyday use is each individual person's personal preference.
you may be more used to DDMMYYYY due to culture, language, upbringing, and usage. in the same vein, i am more used to YYYYMMDD because in chinese we go εΉ΄ζζ₯ (year-month-day), and it makes organizing files and spreadsheet entries much more intuitive anyways.
8
WIZARD POPEπ« - 11mon
Well in that case people should stop complaining about us wanting to use DD.MM.YYYY it's perfectly fine and the only format that should be shot on sight is MM.DD.YYYY
2
ShareMySims @lemmy.dbzer0.com - 11mon
Thank you! π
E: I even said how I can see it being useful in some applications, but fuck, if I'm looking at the date it's almost certainly to see what day it is today, what day (and maybe month) an appointment is, what day some food is going off, stuff like that. I know what month and year it is right now, and if I want to know the time, I look at a clock, not a calendar. If they love extra and often unnecessary information so much they're free to use whatever format they want, but I'm good, and so are many others, and they just need to learn to be ok with that lmao
4
prole - 11mon
Nah. Sort that alphabetically and you end up with a useless list.
1
WIZARD POPEπ« - 11mon
And sorting the other formats alphabetically does not yield the same result?
1
prole - 11mon
No...?
1
WIZARD POPEπ« - 11mon
Okay I don't think I quite get which part you are sorting alphabetically here.
1
dkt @lemmy.ml - 11mon
finally a correct version of this diagram
20
Gork @lemm.ee - 11mon
I often have to refrain myself from using ISO-8601 in regular emails. In a business context the MM/DD/YYYY is so much more prevalent that I don't want to stand out.
Filenames on a share drive though? ISO-8601 all the way idgaf
17
lolola - 11mon
I know, why don't we all agree to agree and use every single possible format within a shared spreadsheet
17
KingOfTheCouch @lemmy.ca - 11mon
Oh god it's so true...
5
random - 11mon
I use ss/mm/hh/dd/MM/YYYY
t.european
16
Maggoty @lemmy.world - 11mon
Mmm US military date and time is fun too.
DDMMMYYYYHHMM and time zone identifier. So 26JAN20251841Z.
So much fun.
14
jagungal @lemmy.world - 11mon
So virtually human unreadable and the letters make machine readability a pain in the ass?
5
boonhet @lemm.ee - 11mon
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.
6
jagungal @lemmy.world - 11mon
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)
6
boonhet @lemm.ee - 11mon
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.
3
Maggoty @lemmy.world - 11mon
As my friend used to say, there's dumb and then there's Army Dumb.
1
Miles O'Brien - 11mon
In one work report, I recorded the date as "1/13/25", "13/1/25" and "13JAN2025"
I have my preference, but please for the love of all that is fluffy in the universe, just stick to one format....
14
uis @lemm.ee - 11mon
"13.1.25", not "13/1/25".
1
azi @mander.xyz - 11mon
Hot take: 2025-Jan-27 is better than 2025-01-27 in monolingual contexts.
11
bigboismith @lemmy.world - 11mon
The beautiful part of 2025/01/27 is that it can inherently be sorted without formatting.
Don't you mean: "Right there! Stop you, I'm going to."
Yoda-ass date structure.
What day, of what month, of what year is it? It's ordered by importance dammit!
12
Track_Shovel - 11mon
25th of July, 2024 is confusing?
There's no ambiguity with the format, since it's impossible to mix up month and day
3
Arthur Besse - 11mon
yes, when the month is written non-numerically (and the year is written with four digits) there is no ambiguity.
but, the three formats in OP's post are all about writing things numerically.
In some contexts, writing out the full month name can be clearer (at least for speakers of the language you're writing in), but it takes more (and a variable amount of) space and the strings cannot be sorted without first parsing them into date objects.
Anywhere you want or need to write a date numerically, ISO-8601 is obviously much better and should always be used (except in the many cases where the stupid formats are required by custom or law).
7
Adm_Drummer @lemmy.world - 11mon
No. But 2024, the 25th of July is clumsy both spoken and written.
July 25th, 2024 is okay but gives off middle child vibes.
25th of July, 2024 is ordered small to big, rolls off the tongue and when written nicely seperates both sets of numbers for ease of readability.
The only other alternative I will accept is Julian dates. Today is Day 26 of 2025.
2
prole - 11mon
July 25th, 2024 is okay but gives off middle child vibes.
The fuck does that even mean? This is literally how people speak dates out loud.
3
Adm_Drummer @lemmy.world - 11mon
It means it gives off middle child vibes. What more do you want?
People round these parts say the day first, then the month. Anything else is attention seeking middle child vibes.
1
I_am_10_squirrels @beehaw.org - 11mon
That's what my work uses
1
uis @lemm.ee - 11mon
Wrong format. DD.MM.YYYY.
1
6mementomorib - 11mon
i never saw year first in Europe.
8
Walk_blesseD - 11mon
You're reading the post backwards.
27
shortrounddev @lemmy.world - 11mon
How is day smaller than month? There are up to 12 values for month, but up to 31 for days
6
Lena - 11mon
It's sorted by the length of time, so a day is shorter than a month.
18
FiskFisk33 @startrek.website - 11mon
obvious troll is obvious
4
RandomVideos @programming.dev - 11mon
Why would the year, the least important, need to be first?
And why are the pieces of the pyramid made so the ISO standard is the only one that looks right? ss:mm:hh:DD:MM:YYYY would also order the numbers based on length, but would look terrible if represented like that
5
spooky2092 - 11mon
Why would the year, the least important, need to be first?
For proper ordering for one. ISO8601 is objectively the best way to label anything that might need to be ordered based on time. This forces data points to line up properly in chronological order, and makes it easy to time slice as needed.
And why are the pieces of the pyramid made so the ISO standard is the only one that looks right?
Because it's the only one that goes from largest value to smallest. It's first because you start from the largest as the base (year) and work down through size to seconds.
ss:mm:hh:DD:MM:YYYY would also order the numbers based on length, but would look terrible if represented like that
Agreed. And any sort of data analysis would be so much harder
21
RandomVideos @programming.dev - 11mon
Arent there uses other than ordering files?
The ISO standard is best for ordering files, but that doesnt mean its good for other things
Its impossible to confuse it with the other 2 presented in this post so you could use it for files and use another one for other things
Edit: i may have been misunderstanding the context in which the ISO standard is claimed to be superior
1
olympicyes @lemmy.world - 11mon
Europe: 10/12/2025
USA: 12/10/2025
If you donβt have context as to which system this is, would 2025/12/10 make things less ambiguous?
7
DarthFreyr @lemmy.world - 11mon
To be fair, proper ISO 8601 specifies hyphens as the separator between date elements, and I don't think I've ever seen a XXXX-XX-XX (with hyphens) be used for YYYY-DD-MM. Just XX-XX could perhaps be ambiguous, but fortunately that's not allowed by the standard, and anyone using just year-day for XXXX-XX is absolutely trolling. YYYY-DDD could have a use, though should really use a separate separator to not sort together IMO. A year-week designation could possibly look like XXXX-XX, but that seems unlikely to just be dropped in that format without context, at least to my western US sensibilities.
4
verdigris @lemmy.ml - 11mon
The fact that you can't confuse it with other formats is precisely the advantage. With any other format (besides the awful lettered month) you have to use context clues to be sure you're reading it correctly if the day is less than 13.
7
JayDee @lemmy.world - 11mon
Well you read the least frequently changing part first, the year, because if you read the seconds first, then the thing's already changed before you've even finished reading it.
/s
4
RandomVideos @programming.dev - 11mon
What about evenly distancing the 3 shortest time intervals to promote fast reading
mm:DD:MM:ss:YYYY:hh
1
MonkderVierte @lemmy.ml - 11mon
I often see the year being the most important in my archive. Followed by month, then day (which is often left out because the document is monthly).
And the why; because it sorts alphabetically.
2
prole - 11mon
Why would the year, the least important, need to be first?
Maybe it's not least important for everyone?
Almost like the preference can change depending on application...
If I'm looking at a folder full of spreadsheets, one each month (or even day) for several years, and they are all titled according to YYYY-MM-DD. All you need to do is sort by filename and now you have it broken down by year, into one spreadsheet per month/day.
And only needed to click one button to sort them into an easily readable format.
2
Lena - 11mon
You can skip the year and just do 1-26
2
RandomVideos @programming.dev - 11mon
Sometimes you need the year
5
prole - 11mon
Yeah it's funny seeing everyone in here thinking only of the one specific thing they use this for, not recognizing that the most useful order can change depending on the purpose of the data.
3
tomenzgg @midwest.social - 11mon
This is Belize and Micronesia erasure.
5
PeriodicallyPedantic @lemmy.ca - 11mon
I just use millis since epoch
(Recently learned that this isn't accurate because it disguises leap seconds. The standard was fucked from the start)
4
lorgo_numputz @beehaw.org - 11mon
This is the way.
2
FartsWithAnAccent - 11mon
Let's do it!
2
DankOfAmerica - 11mon
Y'all be riskin it without holocene crypty
SYSM:YY.DM.TzYDY.H.H
4:40.42p EST on Jan 28, 12,025 ->
4120:20.21.-4285.1.6
That's the one that was active when I started typing. However, I change it randomly using the decay of a radioactive isotope that is randomly chosen by the decay of a separate amount of Uranium-238. I'm two randoms in. This way, my time records are always encrypted using open-science source and the government can't hack the pictures of my parking spots at the oncology center to sell them to the NIMBYs at MetAlphabet AI.
1
lambalicious @lemmy.sdf.org - 10mon
!iso8601@lemmy.sdf.org gang, rise up
Server had been down for about two days but just got it crossposted there, thanks!
lena in 196
ISO 8601 ftw rule
!iso8601@lemmy.sdf.org gang, rise up
MM β MM !!!
"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.
*15th
Keep that kinda talk up and you'll go straight to tariff!
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.
What do you think this is some sort of pyramid scheme?
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. πΊ
https://lemmy.world/pictrs/image/fd1b5ab0-9e0a-4e09-a7dc-0f2133128f1b.png
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 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.
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.
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.
By keeping years in different folders you are just implicitly creating the ISO format: eg.
2025/"04/28.xls"Well, not really. Sort of.
2025/"04-28-2025.xls"
You still want the year in the title format so you have it if it ends up on its own somewhere.
You are looking not for precision but for largest to smallest, descending order. this is distinct from precision, a measure of how finely measured something is. 2025.07397 is actually more precise than 2025/01/27, but is measured by the largest increment.
And to address the argument on precision versus descending. I disagree. An instrument counting seconds is more precise than a machine counting minutes, hours, days, weeks, months etc... And that holds true through the chain. The precision is in the unit.
the unit is just a report of orientation, not magnitude. if you have a digital counter you are limited by the precision of the digital counter, not the units chosen. an analog measurement however is limited instead by other uncertanties. precision has, genuinely, no direct relationship to units. precision is a statistical concept, not a dimensional one.
We can debate this all day. And I can't honestly say that I would take either side in a purely semantics argument.
But the wording comes directly from RFC3339 which is, to me, the definitive source for useful date representation.
https://www.ietf.org/rfc/rfc3339.txt
They chose poor words for this.
Largest to smallest is also wrong. In 2025/01/28, the 28 is larger than the 01.
It should be "most significant" to "least significant"
largest to smallest is correct. 1 mile is larger than 20 meters. if i had specified numerical value or somesuch, maybe you'd be correct. though significance works as well.
Largest to smallest is at best ambiguous. It can refer to the size of the number itself, or the size of the unit.
There is a reason this exact concept in maths/computer science is known as the "significance" of the digit. Eg. The "least significant bit" in binary is the last one.
significance refers to a measurement certainty about a number itself, especially its precision! and is unrelated to the magnitude/scale. the number and dimension "2.5634 mm" has more significant digits than the number "5,000 mm", though the most significant digit is 2 and 5 respectively, and least significant 4 and 5 respectively. this is true if i rewrite it as 0.0025634 m and 5 m. it does work for doing what you say in this case because a date is equivalent to a single number, but is not correct in other situations. that's why i said it does work here.
largest to smallest increment is completely adequate, and describes the actual goal here well. most things are ambiguous if you try hard enough.
My stupid ass read this top to bottom and I was confused why anyone would start with seconds
All my homies hate ISO, RFC 3339 for the win.
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 ...
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
True, that is reasonable. However sometimes it could be represented as scope creep. Depends on the thing, really. The more broad a standard is, the easier it is to deviate from given standard or not implement certain feature because there is not enough resources to do so.
I'd rather have multiple smaller standards than one big. However, I understand your reasoning.
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
Maybe in programming or technical documentation, but no, when I check the date I want to know the day and the month, beyond that, it's all unnecessary information for everyday use, and we have it right in Europe.
You can't change my mind. Β―\_(γ)_/Β―
That's not a good thing. That attitude limits you from improving how you do things because you've gotten emotionally attached to some arbitrary ... never mind. Have a nice day.
These people are just too far into the ISO rabbit hole. I completely agree with you that DD.MM.YYYY is the best format for everyday use.
the "best" format for everyday use is each individual person's personal preference.
you may be more used to DDMMYYYY due to culture, language, upbringing, and usage. in the same vein, i am more used to YYYYMMDD because in chinese we go εΉ΄ζζ₯ (year-month-day), and it makes organizing files and spreadsheet entries much more intuitive anyways.
Well in that case people should stop complaining about us wanting to use DD.MM.YYYY it's perfectly fine and the only format that should be shot on sight is MM.DD.YYYY
Thank you! π
E: I even said how I can see it being useful in some applications, but fuck, if I'm looking at the date it's almost certainly to see what day it is today, what day (and maybe month) an appointment is, what day some food is going off, stuff like that. I know what month and year it is right now, and if I want to know the time, I look at a clock, not a calendar. If they love extra and often unnecessary information so much they're free to use whatever format they want, but I'm good, and so are many others, and they just need to learn to be ok with that lmao
Nah. Sort that alphabetically and you end up with a useless list.
And sorting the other formats alphabetically does not yield the same result?
No...?
Okay I don't think I quite get which part you are sorting alphabetically here.
finally a correct version of this diagram
I often have to refrain myself from using ISO-8601 in regular emails. In a business context the MM/DD/YYYY is so much more prevalent that I don't want to stand out.
Filenames on a share drive though? ISO-8601 all the way idgaf
I know, why don't we all agree to agree and use every single possible format within a shared spreadsheet
Oh god it's so true...
I use ss/mm/hh/dd/MM/YYYY
t.european
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?
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.
As my friend used to say, there's dumb and then there's Army Dumb.
In one work report, I recorded the date as "1/13/25", "13/1/25" and "13JAN2025"
I have my preference, but please for the love of all that is fluffy in the universe, just stick to one format....
"13.1.25", not "13/1/25".
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.
DD-MMM-YYYY master race
https://i.imgflip.com/2jx0wo.jpg
Don't you mean: "Right there! Stop you, I'm going to."
Yoda-ass date structure.
What day, of what month, of what year is it? It's ordered by importance dammit!
25th of July, 2024 is confusing?
There's no ambiguity with the format, since it's impossible to mix up month and day
yes, when the month is written non-numerically (and the year is written with four digits) there is no ambiguity.
but, the three formats in OP's post are all about writing things numerically.
In some contexts, writing out the full month name can be clearer (at least for speakers of the language you're writing in), but it takes more (and a variable amount of) space and the strings cannot be sorted without first parsing them into date objects.
Anywhere you want or need to write a date numerically, ISO-8601 is obviously much better and should always be used (except in the many cases where the stupid formats are required by custom or law).
No. But 2024, the 25th of July is clumsy both spoken and written.
July 25th, 2024 is okay but gives off middle child vibes.
25th of July, 2024 is ordered small to big, rolls off the tongue and when written nicely seperates both sets of numbers for ease of readability.
The only other alternative I will accept is Julian dates. Today is Day 26 of 2025.
The fuck does that even mean? This is literally how people speak dates out loud.
It means it gives off middle child vibes. What more do you want?
People round these parts say the day first, then the month. Anything else is attention seeking middle child vibes.
That's what my work uses
Wrong format. DD.MM.YYYY.
i never saw year first in Europe.
You're reading the post backwards.
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.
obvious troll is obvious
Why would the year, the least important, need to be first?
And why are the pieces of the pyramid made so the ISO standard is the only one that looks right? ss:mm:hh:DD:MM:YYYY would also order the numbers based on length, but would look terrible if represented like that
For proper ordering for one. ISO8601 is objectively the best way to label anything that might need to be ordered based on time. This forces data points to line up properly in chronological order, and makes it easy to time slice as needed.
Because it's the only one that goes from largest value to smallest. It's first because you start from the largest as the base (year) and work down through size to seconds.
Agreed. And any sort of data analysis would be so much harder
Arent there uses other than ordering files?
The ISO standard is best for ordering files, but that doesnt mean its good for other things
Its impossible to confuse it with the other 2 presented in this post so you could use it for files and use another one for other things
Edit: i may have been misunderstanding the context in which the ISO standard is claimed to be superior
Europe: 10/12/2025 USA: 12/10/2025 If you donβt have context as to which system this is, would 2025/12/10 make things less ambiguous?
To be fair, proper ISO 8601 specifies hyphens as the separator between date elements, and I don't think I've ever seen a XXXX-XX-XX (with hyphens) be used for YYYY-DD-MM. Just XX-XX could perhaps be ambiguous, but fortunately that's not allowed by the standard, and anyone using just year-day for XXXX-XX is absolutely trolling. YYYY-DDD could have a use, though should really use a separate separator to not sort together IMO. A year-week designation could possibly look like XXXX-XX, but that seems unlikely to just be dropped in that format without context, at least to my western US sensibilities.
The fact that you can't confuse it with other formats is precisely the advantage. With any other format (besides the awful lettered month) you have to use context clues to be sure you're reading it correctly if the day is less than 13.
Well you read the least frequently changing part first, the year, because if you read the seconds first, then the thing's already changed before you've even finished reading it. /s
What about evenly distancing the 3 shortest time intervals to promote fast reading
mm:DD:MM:ss:YYYY:hh
I often see the year being the most important in my archive. Followed by month, then day (which is often left out because the document is monthly).
And the why; because it sorts alphabetically.
Maybe it's not least important for everyone?
Almost like the preference can change depending on application...
If I'm looking at a folder full of spreadsheets, one each month (or even day) for several years, and they are all titled according to YYYY-MM-DD. All you need to do is sort by filename and now you have it broken down by year, into one spreadsheet per month/day.
And only needed to click one button to sort them into an easily readable format.
You can skip the year and just do 1-26
Sometimes you need the year
Yeah it's funny seeing everyone in here thinking only of the one specific thing they use this for, not recognizing that the most useful order can change depending on the purpose of the data.
This is Belize and Micronesia erasure.
I just use millis since epoch
(Recently learned that this isn't accurate because it disguises leap seconds. The standard was fucked from the start)
This is the way.
Let's do it!
Y'all be riskin it without holocene crypty
SYSM:YY.DM.TzYDY.H.H
4:40.42p EST on Jan 28, 12,025 ->
That's the one that was active when I started typing. However, I change it randomly using the decay of a radioactive isotope that is randomly chosen by the decay of a separate amount of Uranium-238. I'm two randoms in. This way, my time records are always encrypted using open-science source and the government can't hack the pictures of my parking spots at the oncology center to sell them to the NIMBYs at MetAlphabet AI.
Server had been down for about two days but just got it crossposted there, thanks!