There are also variants with single dots too. I sometimes do timestamps without any separator too, depending on the context (such as file backups): YYYYMMDD in example 20260805.
oh yeah. There are numerous benefits to the format itself, outside the question of hyphens vs slashes.
I find the sortability quite satisfying, but also as somebody living in the US, I also like that it's unambiguous regardless of my audience. Hell, half the time I see people hand-write a date on something they don't even use a year.
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
Already saw 1 person write 4/7/26. Writing that 3-4 letters for the month both solves the day/month vs month/day issue, and the off chance someone makes mistake of the month number
Yeah, this is how I do it. Computers are more than capable of handling the three-letter abbreviation for months nowadays, versus some bygone era where perhaps we needed just numbers. This is how I date anything that I need to out a date on.
Was looking for this. Yes. Whenever possible, dates should be specified in a format that is BOTH RFC 3339 and ISO 8601. I'd say both have their quirks, but the intersection of the grammars is machine-parseable and human-readable without (much) legacy baggage or (much) experimental / reserved-for-future-use noise.
Though the way it specifies raw UTC times is odd (8601 uses Z, 3339 uses -00:00), that got changed with RFC 9557 to align with 8601.
It also supports "zoned date times", where instead of just using the UTC offset, you can also include a timezone identifier, e.g. 2020-01-01T00:00+01:00[Europe/Paris]. Useful if you're doing calculations on dates but can be ignored otherwise.
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.
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.
ISO is better for archiving and sorting, inarguably so. But dd-mm-yyyy is better for day to day daily life usage, where the day and month are much more important than the year.
Both have their uses, but for different situations. mm-dd-yyyy is just batshit though.
Yes, ISO-8601 is objectively better than YYYY/DD/MM or MM/DD/YYYY or other strange formats. But, because it isn't the most widely used format, it can be less efficient when there's no danger of MM/DD vs DD/MM confusion.
If person A is talking to person B and they're from the same culture, some culture-specific version like DD/MM/YY might be easier for them because it's what they're both used to, even if it is objectively inferior. But, if person A is talking to person C who is from a different place/culture things get more challenging because if the day of the month is 12 or under, it's hard to distinguish between DD/MM or MM/DD. Even if person C knows that person A comes from a place that does DD/MM, they don't know if person C used the native DD/MM format they're used to, or translated it to them to MM/DD because person A was trying to make things easy for person C.
One of the advantages of the hyphens in ISO-8601, aside from them working with files, is that hyphens in dates are less common than slashes, so if someone sees 1212-11-12 they're more likely to understand that it's an ISO-formatted date. If they see 1212/11/12 it might be a MM/DD date or a DD/MM date.
To be fair, the time separators don't behave well on all implementations of filesystem access by filename. Need to use underscores or omit them at times.
And unlike most „forbidden characters“ for file names, the colon is actually used in NTFS: to separate the file path from the name of a named fork Alternate Data Stream.
"While Galactus has omniscient knowledge of all current user data providers, it doesn't have future sight"
Just use EKS to deliver the feature this quarter, and block the OmegaStar migration on "the team gets their shit together" and supports ISO timestamps.
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.
I think we should all, as a globe, just pick one time zone and use that. I don't care if my 1:00 pm is the middle of that night. Everyone's 5:00pm will be 5:00pm. We will learn how to adjust our schedules for the master time zone.
If you work at a company where all of its offices are in the same time zone and you're time-stamping logs, then it's more expedient for understanding and placing an event in time against other things to use local time.
Unless everything is already standardized as GMT with offset I guess, but I feel like down that route lies madness.
"I got your email at 20:37:45-7:00" is a few more steps than "I got your email at 1:37PM".
It's not a big hurdle, but I try to design for the newest member on the team scrambling in panic rather than a calm cool professional already familiar with conventions.
Now, as soon as we do start dealing with multiple time zones I would just cut my custom time formatting string down to the shorthand to have the scripting language output in the full ISO 8601 format. But until then, being able to easily sort the the date properly and having the time be more human readable is a more "workable" compromise.
Seeing how often I get meeting invites for the wrong time because coworkers ignore my 11 a.m. CDT, and invite me in their timezone, I feel like communicating everything in UTC would be easier, because there could be no confusion.
If you work at a company where all of its offices are in the same time zone
coworkers ignore my 11 a.m. CDT, and invite me in their timezone
PLEASE read the comment you are replying to before submitting your reply.
Even in a single-timezone organization, I think it is still useful to use UTC+offset because it avoids DST confusion and lets the company expand to a second timezone without the team members there feeling second-class. But, GMT+offset does have costs with dealing with people that don't really think about timezones when scheduling, and those costs might overwhelm any advantages.
Now, as soon as we do start dealing with multiple time zones I would just cut my custom time formatting string down to the shorthand to have the scripting language output in the full ISO 8601 format. But until then, being able to easily sort the the date properly and having the time be more human readable is a more "workable" compromise.
At least it saves a "the" and an "of", unless dd/mm countries say "It's 3rd June" or "3 June". Do you not say "the 3rd of June"? In the US you can say "June 3rd". Plus it's natural to line up with yyyy/mm/dd order but in most daily conversations you don't need to say the year.
July 4th is a funny example cause you can say “the 4th” and everyone knows what you mean, but people also say “4th of July” to give it more importance.
That’s a lot less common for other dates, Americans aren’t commonly saying “25th of December”.
same. even if they give a different format, because fuck that I'm not thinking about what arbitrary format you want me to use, I see a date field and I'm filling it out with the proper date format
In spoken conversation it doesn't really matter. In many contexts you could probably just say "Want to go on the third?" and the person you're talking to will understand you mean August the third of this current year.
It does to me. mm-dd is not used at all in my native language and would be considered grammatically incorrect. Since English doesn't prescribe it I have no reason to fully accept it.
Note that I still prefer to write ISO 8601 dates but my spoken dates are big-endian.
Middle-endian dates like "June 15th 2046" are just bad, of course.
I commented earlier that having to say more words is inefficient, but what yiu said made me think... In other languages I know, it's basically spoken as "3rd August'... Eliminating the inefficiency. It's really more English's general inefficiency that irks me, more so than the order of the dates lol
Yes as well (Also insane) but its universally ledgable, sorts on computers easier, accomodates timezones and sub-second units. ISO-8601 should be the universal standard, and anyone who says otherwise better show up with a white paper explaining why. None of this dumb american format or javascript web form bullshit, language is about specificity, BE SPECIFIC. Unless you want to go off the rails and talk about relativity, time dialation and reference points... But thats all above my pay grade. ISO-8601 is a golden example of "good enough for normal people". Thank you for coming to my TEDtalk.
I shorthand it verbally unless I'm giving a full date, but typed, it's almost always yyyy-MM-dd HH:mm:ss (whichever part of that is relevant).
I do this because I believe it's the most logical, it sorts properly without having to use a datetime library, and it can't be confused with another system (is 12-1-2026 in the future or the past? No way to know just by looking at it).
Just shortening it to MM-dd could cause confusion with anyone not in the US so I'll typically include the year as well (also useful if I wind up having to look at old notes or emails to not have to figure out the year I meant ... Which has happened more than once ...)
Only a truly insane person would use mm-dd-yy in conversation. “Want to go to a hockey game with me ten seventeen twenty-six?” Or worse, “…oh four oh seven twenty-seven.” Pure madness.
Conversationally, mmm d yy or d mmm yy (usually just shortened to mmm d or d mmm) is where it’s at.
yes, I'll send dates as mm-dd in my personal life as well. only when discussing exact dates for scheduling things, otherwise in conversational messaging it's mmmm dd
like if we're talking about when we want to go do x activity, I'll propose August 8th. but if we're scheduling trip dates, it's 08-08 through 09-12
We grew up on MM/DD/YYYY but all our computer stuff is YYYY/MM/DD however now that we live in EU we use DD/MM/YYYY and still YYYY/MM/DD for files in pc
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
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.
My comment was about vocal human interaction, not on a device.
I agree with that in principle, but a) it should be in meta data and b) it should be abstracted so the user can display any format they wish. As a last resort, in the file name, sure. That standard adds a lot of extra time gumpf
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.
yyyy/mm/dd, it's less ambiguous and it sorts nicely
Edit: so many replies suggesting using a hyphen as a separator, I'd like to compromise by using the oblique angle sign (⦧) which looks like a slash that becomes a hyphen in the middle. yyyy⦧mm⦧dd
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.
ITT: people saying one thing is better than any other without thinking of context.
If I want to know today's date ISO 8601 isn't a good answer. And if I put stuff in folders by date then DD-MM-YYYY is a real bad way to do it.
But MM-DD-YYYY is the worst one no matter the context.
I became an evangelist for YYYY-MM-DD format once I had to deal with a legal battle that had multiple years of documentary evidence. I sorely regretted my choice of naming files when I had to wade through a heckton of upsetting reminders. It got a lot easier when I renamed everything according to YYYY-MM-DD (and the lawyers probably appreciated it too)
The one you grew up with tends to be your preference. But the usual reason I give for MM-DD-YYYY is it matches how it's said.
December 25th, 2026
12-25-2026
I also know there's no point in arguing about this because, again, my first sentence. It's just team sports stuff, as usual. The only reason why you would bother to argue is if you were trying to convince people to use a standard. But as you pointed out, ISO 8601 already exists. That is the agreed upon standard already. But no one uses it, since we have our preferred systems of date format already ingrained.
I agree, if you truncate YYYY-MM-DD you can only shorten it to showing the year and month. Besides, if I ask someone the date and they start from the year I'll just pull my phone out.
Months are stupid anyway, lets drop them and swap for what they were supposed to represent instead: the moon phase, so today would be 216-2026-Waning Gibbous
ISO 8601 RFC 3339 (yyyy-mm-dd) for storing dates in software. Any format that that goes in the order of day, month, and year for conversational/presentational purposes, preferable the format is dynamic depending on the user's locale (even for those that want the month first). There now everyone is happy.
Edit: switched to RFC 3339 since it is a subset of ISO 8601 that is more strict, and I love semantics.
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.
Damn it I forgot about the duration part of ISO 8601 (which is also super useful and I love it). I'll amend it to RFC 3339 to be more exact in what I mean (even though the specified format should prevent the more esoteric formats).
DD(First 3 of Month, All Caps)YYYY
examples: 01JAN2026, 24MAR1987,20DEC3065
This is how I had to write dates when I worked for a cGMP pharma manufacturing facility and did controlled paperwork. The idea was it was it was impossible for any mistakes when reading the date, only the days were 2 digits, the month was letters, and the year was 4 digits.
Basically all of the validated SOPs were written so that anyone could pick up the paperwork and execute the instructions, and the inverse had to be true as well anyone picking up a completed SOP should be able to read and follow everything written down, and literally every step in the process required initials and date it was executed.
Fun fact, if you fucked up and wrote something wrong or illegibly you were punished twice, once because you had to strike out the mistake, initial date the strikeout and write correctly the next time, and the second was when you get stink eyed by the QA people who have to review all the paperwork before it's scanned and logged back into documentum.
Ya know, I really think every language needs to agree on having a distinct month, day, and year marker to completely eliminate all date confusion. And I mean something universal, even if it's as simple as a sun symbol for days and moon symbol for months, similar to Japanese. Whenever I see a date in Japanese, I am absolutely never confused at all and I appreciate it.
While it's confusing in a vacuum, it's also just the way we say it out loud in american English (April 20, 2026), so it's not that weird when you think about it like that.
However for countries that adopt dd-mm-yyyy, it's also completely natural to say it out loud in that way (20 April 2026).
So by that reasoning we will never end up with a universally accepted date format.
Sorry for the snark, seeing how you seem to be a person, lemme answer more like a person too
First, and most importantly, I think no one should police the way people speak, as long as no harm is done with that speech. Let them express themselves
But also, while less important, "confusing" is just a very normal criticism to make for date formats. Even if they "literally just disagree", the reason they disagree could very well be the fact that other formats are confusing!
But yeah, this is all less important than it seems, you just set up some really low hanging fruit for me with that comment, no hard feelings
DD MON YEAR is the only one that’s not ambiguous on November tenth and the like. 10 Nov 2022 is less confusing than either 11/10/2022 or 10/11/2022 and is without a doubt never confusing.
208 replies
You're thinking to hard. The best way to write a date is Julian. Today is 26216.
Ew.
yyyymmdd
Good luck sorting anything by date!
Y-DDD-MM
It is currently 6-004-08
This is art.
YYYY-MM-DDYep and it needs to use hyphens and not slashes. It helps avoid missed typos or mis-reads in some situations, especially if hand-written.
There are also variants with single dots too. I sometimes do timestamps without any separator too, depending on the context (such as file backups):
YYYYMMDDin example 20260805.and it's perfectly sortable
oh yeah. There are numerous benefits to the format itself, outside the question of hyphens vs slashes.
I find the sortability quite satisfying, but also as somebody living in the US, I also like that it's unambiguous regardless of my audience. Hell, half the time I see people hand-write a date on something they don't even use a year.
ISO 8601 or gtfo
Same but with dots instead of slashes. Otherwise I can’t be sure it’s the right one.
MM/DD/YY
It's an industry standard because it's everywhere. America, fuck yeah!!!
YYYYMMDD is the ISO standard.
The one that ends us with f... I mean ISO 8601 of course
I proper shit post would have suggested “mm/dd/yyyy”.
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
Obviously that's February 26th 2001
You are so evil! :D
For organizing my stuff I use
yyyy/mm/ddbecause in my opinion it's much better for that. Otherwisedd/mm/yyyy.it's either DD/MM/YYYY or YYYY-MM-DD.
That's a red flag... He has obviously not received the xkcd PSA.
There is for everything a
4/Aug/2026
Already saw 1 person write 4/7/26. Writing that 3-4 letters for the month both solves the day/month vs month/day issue, and the off chance someone makes mistake of the month number
Yeah, this is how I do it. Computers are more than capable of handling the three-letter abbreviation for months nowadays, versus some bygone era where perhaps we needed just numbers. This is how I date anything that I need to out a date on.
FAIL
yyyy-mm-dd
Yep. Doing that joke and landing on anything but ISO-8601 would be a huge red flag for me.
This is the answer. So easy to sort.
ISO 8601!
Long live the 8601
my beloved
Being able to sort numerically and have it also be in chronological order is sooo cool.
Lithuania, Hungary, Japan represent
Tik gryžtu ir randu Lietuva.
Based
yep… this or dd.mm.yyyy (for texts)
You're all too ambiguous!
04-Aug-2026 is the only acceptable format
I love when all my reports are listed by day....
Oogh. Such rage bait.
ISO 8601
ISO 8601
ISO week date
RFC 3339 FTW!
Open source, and no ambiguous options grandfathered in.
Was looking for this. Yes. Whenever possible, dates should be specified in a format that is BOTH RFC 3339 and ISO 8601. I'd say both have their quirks, but the intersection of the grammars is machine-parseable and human-readable without (much) legacy baggage or (much) experimental / reserved-for-future-use noise.
Though the way it specifies raw UTC times is odd (8601 uses
Z, 3339 uses-00:00), that got changed with RFC 9557 to align with 8601.It also supports "zoned date times", where instead of just using the UTC offset, you can also include a timezone identifier, e.g.
2020-01-01T00:00+01:00[Europe/Paris]. Useful if you're doing calculations on dates but can be ignored otherwise.👆
This is the only way to date.
No need for dashes
Except for, yknow, human readability
Are a lots of things gonna break in about 8000 years?
I've recently noticed web forms and appointment emails start to use that format. Maybe web devs are sneaking it in bit by bit.
As for why it's better:
ISO is better for archiving and sorting, inarguably so. But dd-mm-yyyy is better for day to day daily life usage, where the day and month are much more important than the year.
Both have their uses, but for different situations. mm-dd-yyyy is just batshit though.
Uh, no.
It literally just depends to what you are used to.
Yes, ISO-8601 is objectively better than YYYY/DD/MM or MM/DD/YYYY or other strange formats. But, because it isn't the most widely used format, it can be less efficient when there's no danger of MM/DD vs DD/MM confusion.
If person A is talking to person B and they're from the same culture, some culture-specific version like DD/MM/YY might be easier for them because it's what they're both used to, even if it is objectively inferior. But, if person A is talking to person C who is from a different place/culture things get more challenging because if the day of the month is 12 or under, it's hard to distinguish between DD/MM or MM/DD. Even if person C knows that person A comes from a place that does DD/MM, they don't know if person C used the native DD/MM format they're used to, or translated it to them to MM/DD because person A was trying to make things easy for person C.
One of the advantages of the hyphens in ISO-8601, aside from them working with files, is that hyphens in dates are less common than slashes, so if someone sees 1212-11-12 they're more likely to understand that it's an ISO-formatted date. If they see 1212/11/12 it might be a MM/DD date or a DD/MM date.
mm-dd-yyyy is sorted by size of number sets. It is no more or less arbitrary than sorting it by size of timespan.
ISO 8601 is the only measurably better format. Otherwise just use whatever you have in your area and don't be a snob about it.
To be fair, the time separators don't behave well on all implementations of filesystem access by filename. Need to use underscores or omit them at times.
And unlike most „forbidden characters“ for file names, the colon is actually used in NTFS: to separate the file path from the name of a
named forkAlternate Data Stream.See, I hadn't even read about this. TIL :)
Still, I use ISO8601 all the time when it comes to written dates :)
This is the way.
This is the way.
This is the (year-month-) day.
RFC 3339
ISO would be great, but sadly OmegaStar doesn't support ISO timestamps yet.
"While Galactus has omniscient knowledge of all current user data providers, it doesn't have future sight"
Just use EKS to deliver the feature this quarter, and block the OmegaStar migration on "the team gets their shit together" and supports ISO timestamps.
Wtf is an omega star?
The last star of the Greek alphabet? 🤷🏻
A Warrior Cats and Omegaverse crossover character
What's a warrior cat
💯
Not shit enough for a shitpost.
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.
There's no way to predict how a date will be used. No reason not to be flexible. No reason to break convention.
That’s how my brother missed a train: the linux planner used GMT while the local train company planner used assumed local time…
So I disagree
Modern problems.jpg
I think we should all, as a globe, just pick one time zone and use that. I don't care if my 1:00 pm is the middle of that night. Everyone's 5:00pm will be 5:00pm. We will learn how to adjust our schedules for the master time zone.
Yeah, the time part should obviously be written in Swatch Internet Time, he writes at @910.
How so, out of curiosity?
If you work at a company where all of its offices are in the same time zone and you're time-stamping logs, then it's more expedient for understanding and placing an event in time against other things to use local time.
Unless everything is already standardized as GMT with offset I guess, but I feel like down that route lies madness.
"I got your email at 20:37:45-7:00" is a few more steps than "I got your email at 1:37PM".
It's not a big hurdle, but I try to design for the newest member on the team scrambling in panic rather than a calm cool professional already familiar with conventions.
Now, as soon as we do start dealing with multiple time zones I would just cut my custom time formatting string down to the shorthand to have the scripting language output in the full ISO 8601 format. But until then, being able to easily sort the the date properly and having the time be more human readable is a more "workable" compromise.
Seeing how often I get meeting invites for the wrong time because coworkers ignore my 11 a.m. CDT, and invite me in their timezone, I feel like communicating everything in UTC would be easier, because there could be no confusion.
PLEASE read the comment you are replying to before submitting your reply.
Even in a single-timezone organization, I think it is still useful to use UTC+offset because it avoids DST confusion and lets the company expand to a second timezone without the team members there feeling second-class. But, GMT+offset does have costs with dealing with people that don't really think about timezones when scheduling, and those costs might overwhelm any advantages.
Did you actually read beyond the first line?
It’s great, and standard for software. But do any of y’all communicate dates like this in your personal life?
Like “want to go to a hockey game with me 2026-10-17?” As cursed as mm-dd-yy is, it feels a lot more natural in conversation.
Say when is that independence day of yours?
There is nothing 'natural' about mm/dd/yy, it is just what you are used to - end of story.
At least it saves a "the" and an "of", unless dd/mm countries say "It's 3rd June" or "3 June". Do you not say "the 3rd of June"? In the US you can say "June 3rd". Plus it's natural to line up with yyyy/mm/dd order but in most daily conversations you don't need to say the year.
I knew I would eat shit for that comment.
July 4th is a funny example cause you can say “the 4th” and everyone knows what you mean, but people also say “4th of July” to give it more importance.
That’s a lot less common for other dates, Americans aren’t commonly saying “25th of December”.
Ok, let me rephrase that: See how 4th of July feels natural for you to say or hear?
That's because you're used to it.
That's how it is for the rest of us using DD-MM-YYYY, but for all dates.
Because that's what we are used to. And yes we use it in everyday life and in every conversation.
That is all there is to it.
I always feel like rolling my eyes whilst Americans slowly drawl the month at me before telling me the day of the month I wanted
“Dec…”
Oh god, you’re American
“…em…”
Here we go, we’re going for it
“…berrrrr”
Yes, we’re getting there
“…rrrrrrr”
Hopefully we get to the date, or I’m going to have to ask someone else
[inhales]
Why did it have to be an American
“Twenty….”
Please not the year
“…-seventh”
Hallelujah, thank the lord, we have a date. Oh Jesus, why such an ordeal. So much time for stupid intrusive thoughts. What was it again…?
Admittedly like most of this is my failings as a person
What you are used to inevitably becomes more natural for you subjectively...
I absolutely fill out dates in iso 8601 any time I'm required to sign a form.
I like your style. I'll start doing that, (unless a format is specified, because I'm no protocol breaker.)
same. even if they give a different format, because fuck that I'm not thinking about what arbitrary format you want me to use, I see a date field and I'm filling it out with the proper date format
dd-mm feels completely natural to say in conversation. “Do you want to go to a X with me on the 3rd of August”
No, but I'll go on August 3rd.
But... what YEAR!?!?
Does "August 3rd" sound unnatural to you?
In spoken conversation it doesn't really matter. In many contexts you could probably just say "Want to go on the third?" and the person you're talking to will understand you mean August the third of this current year.
It does to me. mm-dd is not used at all in my native language and would be considered grammatically incorrect. Since English doesn't prescribe it I have no reason to fully accept it.
Note that I still prefer to write ISO 8601 dates but my spoken dates are big-endian.
Middle-endian dates like "June 15th 2046" are just bad, of course.
I commented earlier that having to say more words is inefficient, but what yiu said made me think... In other languages I know, it's basically spoken as "3rd August'... Eliminating the inefficiency. It's really more English's general inefficiency that irks me, more so than the order of the dates lol
Its fine but its unnecessarily long. Its just one syllable/word but its extra.
Two words when used in a sentence. "The 3rd of August" vs "August 3rd"
I feel like you would only say “of August” if someone is staring at you in abject horror completely untethered from the time stream
Yeah I've been in those calendar meetings too
Yes (I'm insane)
Yes as well (Also insane) but its universally ledgable, sorts on computers easier, accomodates timezones and sub-second units. ISO-8601 should be the universal standard, and anyone who says otherwise better show up with a white paper explaining why. None of this dumb american format or javascript web form bullshit, language is about specificity, BE SPECIFIC. Unless you want to go off the rails and talk about relativity, time dialation and reference points... But thats all above my pay grade. ISO-8601 is a golden example of "good enough for normal people". Thank you for coming to my TEDtalk.
Yes, kind of.
I shorthand it verbally unless I'm giving a full date, but typed, it's almost always yyyy-MM-dd HH:mm:ss (whichever part of that is relevant).
I do this because I believe it's the most logical, it sorts properly without having to use a datetime library, and it can't be confused with another system (is 12-1-2026 in the future or the past? No way to know just by looking at it).
Just shortening it to MM-dd could cause confusion with anyone not in the US so I'll typically include the year as well (also useful if I wind up having to look at old notes or emails to not have to figure out the year I meant ... Which has happened more than once ...)
Only a truly insane person would use mm-dd-yy in conversation. “Want to go to a hockey game with me ten seventeen twenty-six?” Or worse, “…oh four oh seven twenty-seven.” Pure madness.
Conversationally, mmm d yy or d mmm yy (usually just shortened to mmm d or d mmm) is where it’s at.
There's no reason the two need to be the same. We don't talk in heximal either
I spell out the month, but I'm fancy
yes, I'll send dates as mm-dd in my personal life as well. only when discussing exact dates for scheduling things, otherwise in conversational messaging it's mmmm dd
like if we're talking about when we want to go do x activity, I'll propose August 8th. but if we're scheduling trip dates, it's 08-08 through 09-12
We grew up on MM/DD/YYYY but all our computer stuff is YYYY/MM/DD however now that we live in EU we use DD/MM/YYYY and still YYYY/MM/DD for files in pc
YYYYMMDDHHMMSS
Please use any kind of separation character or I'm gonna lose my mind
It's easy once you get the hang of it
Best I can give you is a single "_"
202609041006_15
Most evil place to put it.
Noar
But you'll end up with months instead of minutes!
yeah yeah a bit confusing lol
I feel like DD/MM/YYYY is the same as doing: ss:mm:HH and I find that confusing.
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
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.
Files get sorted by alphanumerical order so ISO 8601 (YYYY-MM-DD) is objectively superior in that regard.
My comment was about vocal human interaction, not on a device.
I agree with that in principle, but a) it should be in meta data and b) it should be abstracted so the user can display any format they wish. As a last resort, in the file name, sure. That standard adds a lot of extra time gumpf
I read this meme and was physically revolted and wanted to immediately down vote. Great job.
The superior date format is, of course, ISO 8601. YYYY-MM-DD.
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-1is 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/
https://xkcd.com/927/
yyyy/mm/dd, it's less ambiguous and it sorts nicely
Edit: so many replies suggesting using a hyphen as a separator, I'd like to compromise by using the oblique angle sign (⦧) which looks like a slash that becomes a hyphen in the middle. yyyy⦧mm⦧dd
nerd detected
lmftfy: american nerd detected
What's American about ISO 8601 with slashes?
Edit: typo
*ISO 8601
i don't think ISO 8601 allows slashes.
but: you are right, and i was not aware: many countries use the
/for dates: https://en.wikipedia.org/wiki/List_of_date_formats_by_country i thought this was a USA thing... thanks for the hint!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.
HISSSSSS.
switch the slashes to dashes
[Angry ISO-8601 noises]
I should turn your comment into a shitpost...
She seems impressed
Every fucking time they make him look like a tool.
He formats dates, how else would he look like?
ITT: people saying one thing is better than any other without thinking of context.
If I want to know today's date ISO 8601 isn't a good answer. And if I put stuff in folders by date then DD-MM-YYYY is a real bad way to do it. But MM-DD-YYYY is the worst one no matter the context.
I like YYYY-MM-DD because then I don't have to figure out half the time if they used MM-DD-YYYY or if they were sane.
I became an evangelist for YYYY-MM-DD format once I had to deal with a legal battle that had multiple years of documentary evidence. I sorely regretted my choice of naming files when I had to wade through a heckton of upsetting reminders. It got a lot easier when I renamed everything according to YYYY-MM-DD (and the lawyers probably appreciated it too)
Can be tailed to the relevant bit though.
The one you grew up with tends to be your preference. But the usual reason I give for MM-DD-YYYY is it matches how it's said.
December 25th, 2026
12-25-2026
I also know there's no point in arguing about this because, again, my first sentence. It's just team sports stuff, as usual. The only reason why you would bother to argue is if you were trying to convince people to use a standard. But as you pointed out, ISO 8601 already exists. That is the agreed upon standard already. But no one uses it, since we have our preferred systems of date format already ingrained.
FYI it’s not really said like that elsewhere, they say
“(Friday the) 25th of December, 2026”
As someone from elsewhere: we dropped the "of"
And no, since I genuinely heard that before, 25th December does not imply that there are 24 other months called December.
No, you only say the 4th of July that way
No, you only say the 4th of July that way
I agree, if you truncate YYYY-MM-DD you can only shorten it to showing the year and month. Besides, if I ask someone the date and they start from the year I'll just pull my phone out.
Months are stupid anyway, lets drop them and swap for what they were supposed to represent instead: the moon phase, so today would be 216-2026-Waning Gibbous
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.
1785793853 seconds since Linux epoch
Anyone who wants to write the millennium between the month and century loses all credibility when arguing about date formats.
YYYY-MM-DD is the only coherent date format.
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
ISO 8601RFC 3339 (yyyy-mm-dd) for storing dates in software. Any format that that goes in the order of day, month, and year for conversational/presentational purposes, preferable the format is dynamic depending on the user's locale (even for those that want the month first). There now everyone is happy.Edit: switched to RFC 3339 since it is a subset of ISO 8601 that is more strict, and I love semantics.
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-1is 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/
Damn it I forgot about the duration part of ISO 8601 (which is also super useful and I love it). I'll amend it to RFC 3339 to be more exact in what I mean (even though the specified format should prevent the more esoteric formats).
DD(First 3 of Month, All Caps)YYYY examples: 01JAN2026, 24MAR1987,20DEC3065
This is how I had to write dates when I worked for a cGMP pharma manufacturing facility and did controlled paperwork. The idea was it was it was impossible for any mistakes when reading the date, only the days were 2 digits, the month was letters, and the year was 4 digits.
Basically all of the validated SOPs were written so that anyone could pick up the paperwork and execute the instructions, and the inverse had to be true as well anyone picking up a completed SOP should be able to read and follow everything written down, and literally every step in the process required initials and date it was executed.
Fun fact, if you fucked up and wrote something wrong or illegibly you were punished twice, once because you had to strike out the mistake, initial date the strikeout and write correctly the next time, and the second was when you get stink eyed by the QA people who have to review all the paperwork before it's scanned and logged back into documentum.
While personally I agree with you at the ddMMMyyyy superiority, it is kind of confusing in international markets.
The French words for June and July both start with Jui amongst other problems.
I'm a YYYY/MM/DD man myself
[ISO-8601 MAN SWOOPS IN FROM THE SKY]
You are close, work on your punctuation, see me after class
[Dramatic super hero exit]
Wow, I was really not expecting us to get this far into the weeds in this thread but I suppose I should have lol
I prefer ddd/yyyy, much simpler
Ah yes,
Mon/2026, perfect…Gives you (up to) 52 shots at any plans, perfect
%j/%Y
even simpler, it's all numbers.
April 25th.
We've already established this.
Because it's not too hot and not too cold. All you need is a light jacket.
I can tell I'm on Lemmy because of how many ISO 8601 comments I had to scroll past to find this comment.
FYI that’s about 218°C
53 comments and I'm the first effusive nerd to bring up unix epoch? Nothing happened before 0 (1970-01-01 00:00:00) anyway.
Epoch is signed though, that 1970 date is the midpoint
YYYYYMMDD
I prefer to think we're in the year 12026, since homo sapiens really got things going around 10,000 BCE.
Ya know, I really think every language needs to agree on having a distinct month, day, and year marker to completely eliminate all date confusion. And I mean something universal, even if it's as simple as a sun symbol for days and moon symbol for months, similar to Japanese. Whenever I see a date in Japanese, I am absolutely never confused at all and I appreciate it.
Can we make every month 28 days while at it?
Im more of a Medjool guy myself. Not sure what everyone else is talking about.
That or the reverse.
Apparently im a freak who is MM/DD/YEAR.
Also known as an American™️
Yes, you are and you should feel shame about you.
While it's confusing in a vacuum, it's also just the way we say it out loud in american English (April 20, 2026), so it's not that weird when you think about it like that.
However for countries that adopt dd-mm-yyyy, it's also completely natural to say it out loud in that way (20 April 2026). So by that reasoning we will never end up with a universally accepted date format.
Yep, I agree. There's no wrong answer, and language differs by culture.
There's a right answer, and it's yyyy-mm-dd.
That's MMM d yyyy, not mm dd yyyy. It removes the ambiguity but also removes the sortability. yyyy-mm-dd for the win.
I think it's better than day month year but both are worse than year month day.
https://www.trekterest.com/stardate
Correct opinion.
That's a path I can't walk buddy, I think it's better we end it here before we get too attached.
3 Aug 2026
You can’t guess wrong.
The Spanish would write Ago
The French would write Août
The Greek would write Αυγ
Arabic speaking would write أغسطس
Using words doesn't seem as universal as numbers.
Good point. This format only works if the reader knows the language.
February 23.
Because it's muh birfday 😋
@[email protected] pm 2027-02-23
man dateit's like looking into a mirror
"confusing" you're dumb and/or likely being obtuse
"Dumb" or "it's bad" is fine.
But being confused by stuff you just disagree with has to stop
Your complaints are confusing.
:(
Sorry for the snark, seeing how you seem to be a person, lemme answer more like a person too
First, and most importantly, I think no one should police the way people speak, as long as no harm is done with that speech. Let them express themselves
But also, while less important, "confusing" is just a very normal criticism to make for date formats. Even if they "literally just disagree", the reason they disagree could very well be the fact that other formats are confusing!
But yeah, this is all less important than it seems, you just set up some really low hanging fruit for me with that comment, no hard feelings
Have a nice day!
DD MON YEAR is the only one that’s not ambiguous on November tenth and the like. 10 Nov 2022 is less confusing than either 11/10/2022 or 10/11/2022 and is without a doubt never confusing.
yyyy-mm-dd is an international standard. It's better because it's sortable.
When I was doing data entry we did MMM-DD in folders with the year name, as yet another option.
Apr Aug Dec Feb Jan Jul Jun Mar May Nov Oct Sep
Perfect