While I agree that big-endian dates are the best solution (if nothing else, because lexical sort puts it in the right order), I think little-endian at least makes sense. The middle-endian format is just absurd.
Yes, but the confusion caused by not knowing which way your writing it makes both ways worthless (unless your audience is strictly IN or OUT of the US - OR - if one number is greater than 12).
It's annoying, and I just ALWAYS use YYYY-MM-DD, and everyone is happy. Please join my cause. If there's one thing we can all agree makes the world just a little better, it's using YYYY-MM-DD to get people used to it.
I'll use YYYY-MM-DD a lot of the time when doing computer related stuff, but out in the wild I'll tend to do little-endian but write the month as three letters. E.g. 26 Mar 2023.
Middle-Endian is how it tends to be said out loud in English. Even in countries that would write 25/3/23, you still usually answer "What day is it?" out loud with "It's March 25th" rather than "It's the 25th of March." And after that point, the year going at the end makes sense because people are generally not asking what year it is. The only thing that makes it confusing at all is Europe choosing to do it differently without a clear way to tell which system is being used in some cases (you could say this about timezones as well, and would be right to complain there as well, but that doesn't mean that someone's particular timezone is "more correct").
In my opinion though, using a number for the month at all is silly. Nobody ever answered "What month is it?" with "Five." A better format would be to use standard 3-letter codes for the month, e.g. MAR:25:23.
This isn't true in British English, at least in my experience. We'd say "25th of March". The "of" would be omitted when writing a sentence, but you'd include it when reading aloud.
To be honest, using date formats in Asian languages (Korean/Japanese/Chinese) is probably the best. There is zero confusion, as the word for "month," "day," or "year" proceeds the numbers directly: 2023년 3월 25일 in Korean, or 2023年3月25日 in Chinese (and Japanese?).
What do you mean by "wrong?" And why should logic trump practicality? Besides, rightness and wrongness are value judgments. They have nothing to do with logic.
M/D/Y seems to be the most practical because it reflects how dates are spoken in American English. It separates the date (month/day) from the year, which in many cases can be omitted, while also keeping the larger unit, the month, up front.
"wrong" was in reference to the post being replied to.
The majority of English speakers and people in general don't speak American English, so it makes zero sense to default to "M/D/Y", unless the user explicitly states to use American English, over a more logical order, ideally Y-M-D.
Pretty much all defence in this thread of M/D/Y is just American exceptionalism.
I'd much rather have D/M/Y, since then data is ordered by relevance. If I'm seeing a full date, I probably care more about the day than the month, and more about the month than the year. This is just pure bikeshedding tho, both are infinitely better than M/D/Y
Relevance changes by which time scale you're looking at. If you're looking at the last month, the day is most important. If you're looking at last year, month is probably most important. And for anything beyond a year, year is obviously most important.
I agree with you. Year is least likely to change, then month, so you can pay attention to D, and scan M/Y which I feel takes less attention than other formats
I tend to do important things in the second half of the month. That way, you don't get an ambiguous 10/09/22 but a less ambiguous 10/17/22. Everybody still needs to be aware which year we are talking about, but you tend to just write day and month anyway, so 10/09 is bad while 10/17 is obvious.
Hell, the weird American "write it like you say it month dayeth of year" would be fine if they didn't use slashes. Sure it doesn't sort well but at least it wouldn't be ambiguous. Nobody would be confused if today was written 03-25/2023.
No, it doesn't. I mean, in certain contexts it can, but it doesn't exclusively in general, any more than it means “and/or” exclusively in general (though, it does mean “and/or” in “and/or” which probably isn’t something you should think about too much.)
It can just be a separator, as it is in American dates.
Fair point about and/or, but there's still a consistent pattern to that usage - also he/she, etc. I'm having trouble coming up with cases besides US dates where it isn't used to mean one of these two things:
"of": like one half (1/2) meaning one of two, or km/h meaning kilometers per hour, or page 14/55. In these contexts it means something within something else. In both cases there's the strong mathematical connotation of a numerator and a denominator.
"or": like in and/or or he/she.
The symbol has clear connotations, and the American date-format deviates from those.
One thing I've come to learn is that American formats are human-friendly rather than machine-friendly.
Our date system is like the Fahrenheit system; it works well when thinking like a human.
in Fahrenheit, you just think of it in terms of 50 being the middle, "not cold and not hot". Then you understand 80 is high warm, closing in on hot, etc.
Similarly for our date system, we lead with names and important information rather than numbers. We're not feeding a number into a machine, we're speaking to humans.
Consider any other Label. You don't say "25th Apartment", you say "Apartment 25", "Unit 25", "P.O. Box 25"
Here we are on March 25. The year comes last because it's least important.
Yeah, I don't think so. If it's 0°C outside, I know it's probably time to put winter tires on because the water in the puddles will freeze. If water in the pot on my stove is close to 100°C, I know it will boil soon. Same with dates — it has nothing to do with being machine readable or not, dates should go from largest to smallest (yyyy-mm-dd, etc) or vise versa, not turn 180 degrees at midpoint for some reason. Your units make no sense, you're drawing the bullseye afterwards if remember my idioms correctly.
I am usually an apologist for imperial units thanks to the divisibility by 3 and "human" scale, but temperature is ironically the one that I think is the silliest. It's basically arbitrary.
The original idea of Farenheit was that 0-100 was the range between the freezing point of salt water and human body temperature, and it was designed to be convenient for use in labs. At the time, 0F was the coldest temperature you could reliably make in a lab environment (using a saltwater ice bath). 100F was when the thing started to be uncomfortable to touch, I guess?
Sure, as an American living in the northeast, it is pretty convenient for my current use - temperatures vary from 0 (sometimes below) to a little less than 100 over the year and I know what "jacket weather" is - but that doesn't really mean anything if you don't live in this exact climate. I imagine that if we switched to Celsius tomorrow, after re-learning the numbers for "put on a sweater" and "put on a jacket," it would be about the same.
> 100F was when the thing started to be uncomfortable to touch, I guess?
“Uncomfortable to touch” heavily depends on thermal capacity (how much heat there is in the object to touch) and thermal conductivity (how fast the object can get that heat into your skin), so I would think defining that exact point to be quite the challenge.
“The other limit established was his best estimate of the average human body temperature, originally set at 90 °F, then 96 °F (about 2.6 °F less than the modern value due to a later redefinition of the scale)”
So, Fahrenheit arbitrarily picked 100 °F as some distance above the point for average human body temperature, changed it to 96 °F, and the scale was later redefined.
And still people claim that scale is less arbitrary than Celsius, Kelvin, Réaumur, etc.
The lethality greatly depends from place to place and that's hardly "extreme outliers". For example Hong Kong's record low temperature is 0.0 °C [1] and a single digit Celcius is considered "very cold"; people can and do die of hypothermia at that range if they are "poorly prepared".
> Here we are on March 25. The year comes last because it's least important.
Sorry to break it to you, but in the UK, Australia or India you wouldn't say March 25, you would say 25 March or 25th March. Just as you would in Spanish, French or German. The fact that you say March 25 reflects the atypical American date standard. They do say March 25 in Chinese, but that's because they use YMD order (and when saying a full date, they will say "2023 year, 3 month, 25 day") which also makes sense.
There's nothing more "human-friendly" about saying March 25. It's a purely American thing. There's also nothing more "human-friendly" about Fahrenheit. If you grow with Celsius, 20-25 is optimal, 10-20 cool, below 10 cold, below 0 freezing, over 30 very hot, nothing difficult about it.
Sorry if this sounds harsh but your comment is pure distilled bias.
>in Fahrenheit, you just think of it in terms of 50 being the middle, "not cold and not hot". Then you understand 80 is high warm, closing in on hot, etc.
You could say the exact same with Celsius. Also, how is 50 the middle in Africa and also Northern Europe? Average temperature is very different.
>Here we are on March 25. The year comes last because it's least important.
So 25 is clearly the most important by your own logic hence day/month/year is the logic choice. If someone asked the date do you say “the 25th” more or less often than “March 25th”? Most people know the year so that can be skipped. Many know the month so that can frequently also be skipped. Hardley anyone that ask for the date know the day of the month though so why is that not the first part of information you reply with?
> Consider any other Label. You don't say "25th Apartment", you say "Apartment 25", "Unit 25", "P.O. Box 25"
That’s very obviously cherry-picked though. The opposite is true for the names of numbered streets (“9th Street”) and house numbers (“1600 Pennsylvania Avenue”). You picked the only component of an address where the number comes after the label.
I’ve heard that a few times, but personally as someone that is a human as far as I know, I've never been able to grok Fahrenheit like I can Celsius! Celsius slots into nice groups of 10 where 0ish is very cold, 10ish is cold, 20ish room temp, 30ish is summer heat.
It’s less of an inherent part of the system, and more of a fact I just grew up with it and it’s what I’m used to.
Firstly this logic doesn't hold water. Month is not the most important, day of month is. "What date did you mean?" can easily be answered with "the 25th" if it's a nearby date, month only becomes relevant if disambiguation is needed.
Secondly this is 1000% purely what you're used too. After a month in California Fahrenheit felt very natural to me despite being used to Celcius.
The great way to imply that non-Americans are not "like a human".
> Similarly for our date system, we lead with names and important information rather than numbers.
If I say March 30, the year number is implied (probably this year) and I probably have omitted it because it is not as important enough to say again.
If I say 2023-03-30, the year number is probably important. Might not that important, but at the least I'm looking for future readers who might not realize that I've made this comment in 2023. The year number is thus as important as month and day of month here, so consistency matters more. And the American mixed endian date format is as inconsistent as mixed byte endianness (which is thankfully gone by now).
I'm biased since I grew up with mm/dd/yy format, but I do find month first more useful simply because the 30-day period something takes place in gives me more context immediately about an event, at least when talking about scheduling things.
The year is typically implied, so it's not needed. The actual day of month gives you more specificity, but the month is an easier "chunk" to keep in my head when thinking about a date. If I think about my next dentist appointment, just knowing that it's in September is more useful to me than just knowing the actual day of the month.
50 being the middle is region specific it doesn't work the same way in all countries.
Also isn't it better to just say 25th March rather than March 25? Because most people will be aware of the month we're talking abt and date is the most important thing there which should come first.
water freezes at 0, boils at 100. this is an excellent and intuitive scale for a human that is 70% water. The SI units, like kg or m are characteristic of the human scale. and more importantly, sanely decimal.
and you say 3rd street, not Street 3. and 4th of july
i do prefer the american decimal point 1,000.00 , it makes more sense. But it's time for humans to quit our nonsense and give way to machines , which require universal standards.
> water freezes at 0, boils at 100. this is an excellent and intuitive scale for a human that is 70% water.
This is a stretch. How is being 70% water relevant? It’s not like I’m routinely measuring the water in my body to make sure I don’t let it boil or freeze.
That’s why I say 11rd Street and set my hot pot to 1100100 degrees. The added benefit is I can now do math on my fingers with a 100x greater range! Bring in toes and it gets insane.
I feel like people like you should be required to use | and O instead of 0 and 1. You don't get to spoil our perfect arabic numerals for your numerical travesty. begone, you wasters of bytes
In reality I encode everything in raw bits but for these Europeans I convert to their hippy Unicode whatever. Why use 7 bits for a character when you can use UTF-8/16/32 - the “metric system” of encodings.
> in Fahrenheit, you just think of it in terms of 50 being the middle, "not cold and not hot". Then you understand 80 is high warm, closing in on hot, etc.
Depending on where you live, 50F could be considered cold. It's certainly not warm enough to be comfortable when lightly dressed.
There's nothing special about Fahrenheit in this respect. 20C is really what I'd call "not cold, not hot". 0 is freezing, 5 is cold, 10 is chilly, 15 is cool, 20 is comfortable, 25 is warm, 30 is high warm, 35 is hot, 37 is body temperature, and 40 is really hot.
On the other hand, the German way of speaking numbers with the order of just the 2 least significant digits flipped between numerical notation and speaking/writing is also easier explained by culture and history, rather than good logic.
The English equivalent for 1125 would be onethousand-onehundred-five-and-twenty.
I think their point is that the American date format is natural in the context of English grammar. Which it is, but written dates serve more purposes than acting as a record of things people said.
I feel you...I'm not German myself. It's quite annoying, and every time I want to be sure that the number I speak is understood properly, I give it number by number. I've seen too many Germans having issues with that myself, and it's just too risky with foreigners.
Interestingly, I've rarely seen it being an issue with dates. Maybe because the amount is too small and people got used to it.
If someone at work asks me the date or if I’m signing in somewhere as a visitor and I ask the date, the response is the same: “the 25th”. The month is expected to be somewhat obvious. The year even more so.
If I’m giving or getting a response with the month I expect “25th of March”.
If I ask for the time and it’s the evening I expect someone to say “3:30” without the PM. It’s expected that I know it’s PM. In continental Europe I would expect “15 hours 30”.
Going to your address analogy, don’t you typically give the building number first? “1220 Something Street”. Again, with numbered streets in North America they tend to write and say “122nd Street” or “5th Avenue”. It’s the number that comes first. Not “Street 122” or “Avenue 5” or “Something Street 1220”. I don’t think your analogy holds well.
I keep seeing Americans claim that, but I really think your perception of this as more "more human-friendly" is really just a result of growing up with it.
Date format should flow from smalles to largest units. That is human friendly. When the rest of the world says 25th March, it's more human friendly for two reasons:
1. The most important part is the day, and that comes first.
2. The month only changes every 30/31 days, so for that duration it is enough to just say "Today is the 25th" therefore cutting the need for the bit that we already know (that is March). Similarly for the year, you don't mention that it's 2023 for a whole year pretty much.
All of this is a matter of habit. I assure you as someone who grew up with Celsius system, we have no problem translating temperature ranges to the levels of comfort and clothes layering. European mailing addresses start with the biggest addressable unit (country) and then drill down to region, city, street, house number, unit number which is actually closer in spirit to your “lead with important information” example.
But usually I know what the month is. Pre-qualifying a unit number with the "type" makes sense because I don't necessarily know what the number refers to advance. And sure, just for grammatical consistency and flow it's fine to say the month before the day. But it's another story in writing, especially on forms, or even worse, in data sets.
You seem to be the lucky lightning rod comment on this!
I guess it's fitting that the tech world gets particularly up in arms about this; we're certainly a group who enjoys demanding standardization while refusing to change our own practices.
(But also, if you're not using ISO 8601 in a code context, what are you doing?)
Excuse me, but can you please expand upon how Fahrenheit is easier "when thinking like a human"? Why 50? Why not 100? Why not simply use something that is easily compared, such as the freezing and boiling point of water? You know... Celsius?
you may as well ask why 100% doesn't represent "half". Fahrenheit is best thought of as a range from 0 to 100, the numbers outside of which are extreme outliers
For anybody looking to build a real clock, please don't use `setInterval`. Instead, use `requestAnimationFrame` which will avoid awkward stutters and delays. With a second-by-second timer, `setInterval` routinely results in seconds that appear too short or too long (in this case, up to the interval time of 100ms).
Also, it's nice to see that this simple page isn't using any framework. One quick performance win is to cache the `querySelector` calls. Those will be the slowest part of the computation, and the nodes themselves never change.
I've settled on the explanation that this is just a cultural difference, and anyone arguing from a place of "logic" or "correctness" is refusing to accept that it's all convention, and different people do things differently.
As an analogy, some languages put the verb at the end of the sentence (e.g. Latin, certain German grammatical structures). As an English speaker, this is weird because I don't really know what's going on until the sentence is done, and it feels like I'm putting together a little puzzle in my head. Whereas to a fluent speaker, it presumably just makes sense and you don't really find it difficult. Same thing with dates.
As an American, I like our convention for writing dates. I usually care about month first. Immediately upon seeing a date, I know the rough time frame. Is it this month? Next month? Around Christmas? Around my birthday? Then the day pins it down to something specific. I will assume a date is referring to the current year, unless I see a different year, in which case it's a quick update to my mental model. April 12 flows as "soon, and exactly 18 days away" and September 12 flows "far away, and the middle part of the month".
I get that computers are a different use case, and there I'm a ISO 8601 advocate.
"4th [of] July, 2023" and "July [the] 4th, 2023" are both valid - I'd bet there's a correlation between spoken order and written order, but not sure which caused which (or maybe mutually reinforcing).
The monkey’s paw curls, and Americans adopt this time format as well just to spite the rest of the world for complaining about their preferred date format.
For many years I've used e.g. 2023 Mar 25, in the spirit of ISO 8601, to avoid all these problems.
I say "in the spirit of" because, as I recall (it's been years since I read it), the standard is quite focused, whereas I just want to do Year/month/day regardless of other little details like punctuation / numeric vs named month / zero padded digits or whether there should be a timezone etc etc. Usually I'm just adding a date to private notes, so it really doesn't matter.
When I have to fill out official forms on paper, I have to make an effort to change my habit.
Fun fact, the Apollo computer used the metric system internally and patronizingly displayed freedom units because the astronauts supposedly couldn't handle it.
You're thinking of the Mars Climate Orbiter, where the mistake was between NASA and Lockheed Martin, both American. Besides that, the issue wasn't the specific unit system used, it was NASA not testing to make sure their specifications were met before launch and then being too bureaucratic to react in time. The exact same issue could happen in metric with CGS vs MKS.
Ooh, let's play this game. Which date format was used to launch the first sattelite and human into space? What date format is used on the ISS and in the Hubble Telescope?
Should we list hours, minutes, seconds? or year, month, day? Should we drive on the right side of the road or left? Should we use imperial or metric system? These are all good questions but I think the answer is "it depends." Just like timezones. You can't get rid of timezones: https://news.ycombinator.com/item?id=26416337
Those two seem very clear-cut. I haven’t ever seen time in any other format (HH:MM does not count as a different format), and there is zero benefit to the imperial system, other than Americans being used to it.
> Should we drive on the right side of the road or left?
I don’t think there’s much benefit in picking one over the other that isn’t related to economic factors (such as being able to import cars from neighbouring countries, but also the cost of redesigning all roads).
I dimly remember trying this five years ago and it being a bit of a mess. IIRC it was that date picker widgets in browsers presented in a different format to what the Accept-Language header suggests (a killer when you're trying to render static and editable dates in the same table), or users were confused seeing dates in their preferred format after being linked from a site that disregards them, etc. Perhaps the situation has improved by now.
Seems like requiring the date author to think about widgets is too much of burden. Better to just leave it as text and have an annotation layer that optionally says "this substring is a date in format X with timezone Y" which viewers can optionally re-render according to their preferences.
That way if neither option is exercised, it's still just text.
I moved to the US from a country using metric system and different formats for things like date and currency. I don't really find the difference important at all and have no trouble switching between units and formats (my job requires me to exchange information with teams in Europe and Canada). I did find that for the sake of avoiding misunderstandings date should always start with the year. It's also good for sorting files and folders. Daylight savings time is the only thing I wish we didn't have in the US.
I have lived in English and Metric countries and have had no trouble with formats or units. I think it is because I didn't try to convert anything, just learned it as a new system. My wife on the other hand had a bunch of mental trick to convert between Metric and English, but she also never had any trouble with date or time formats.
The biggest problem to me is time zones and summer/winter time. I wish we all used UTC.
the least ambiguous format i know for human-facing dates:
%d %b %Y
so today is 25 Mar 2023.
not coincidentally, this format is in common use in the american military. Occasionally my use of it has had people ask me where i served, though i never have.
A fun fact about ISO 8601... it mandates[0] use of the proleptic Gregorian calendar for dates earlier than 15th October 1582. Now, in that calendar there is a year zero - so anyone using the proleptic Gregorian calendar can say that the 3rd millennium began on 1st January 2000, instead of the pedant's preferred date of 1st January 2001.
Since ISO 8601 is baked into so many modern systems and standards, and since software has eaten the world, there's a real sense in which we are all using it as our primary calendar - and thus for those of us who were celebrating on 1st January 2000, we can retro-canonically rest in peace knowing the fireworks were not mistimed after all.
[0] OK, there's some fuzziness in the wording, where "mutual agreement" must be sought before exchanging such earlier dates.
We think units that are used in different countries/cultures/continents are weird, because we’re not used to it. I can get behind the Fahrenheit bit, being more “human-readable” but for me 30C will always be hot.
This only makes sense from a euro-centric view of the world.
Month before Day is most compliant with the international standard for date (ISO 8601). We use Year-Month-Day fairly frequently in the United States too (though the most common is Month/Day/Year).
This is what I use to name files I want to sort by date. America uses the wrong date format, and is also one of only three countries that doesn't use metric (the U.S, Liberia, and Myanmar).
Every Chinese engineer I work with knows how to measure in li, fen, & jin; the Japanese measure floor area in tatami, etc. I think you're conflating customary units with scientific units. Most of the world uses local, customary, units. The US — like most of the world — uses metric for science stuff.
Europeans have access to multiple countries, cultures, and languages, yet still complain about imperial units, date formats, "soccer," SMS, and all of the many other ways in which the United States differs. It's another country. Stop being so insular.
It's pretty silly when people complain about different tastes in subjective areas, such as music, architecture, pronunciation, food or other cultural differences. However, when it comes to methods of technical communication such as time formats or measurement units the complaints have little to do with subjective preferences, and more to do with real world consequences of maintaining unintuitive systems. Technical language should be clear, precise and uniform. That's what it's for. Insisting on maintaining different standards causes real headaches for everyone who has to deal with those systems, and sometimes can cause catastrophic errors. It has little to do with preference, and much more to do with practicality.
It's okay if there are differences. Arab-speaking countries use RTL, which causes huge issues everywhere. We don't tell them to change their language, we just adapt to it. Software developers are not using M/D/Y anyway, and everyone else who deals with international business should already understand the difference. When I see a non-American date, I assume D/M/Y. It shouldn't be that hard to expect supposedly cosmopolitan Europeans to do the same.
> Software developers are not using M/D/Y anyway, and everyone else who deals with international business should already understand the difference
That's a pretty major assumption that does not jive with experience. Date formatting inconsistentices were the bane of my existence in my last role. Maintaining clean databases that has input streams that came from Canada, the US and Poland constantly caused problems. Yes the company had standards of how to properly do things. Were those standards followed? Not all the time. Especially when data sources came from 2nd and 3rd tier downstream suppliers. Did people try their best? Yeah, for the most part. But that doesn't prevent mistakes.
For example, if your company has a splunk install for log surveillance, it has a default of M/D/Y year format for all date ranges etc, it's a bit confusing, but it has localization too of course.
Developers who do devops tasks might run into this one.
Developers? Maybe but even if we accept that all developers pay close attention to their date formats to avoid misinterpretation errors, others who produce work within the developers workflow are certainly not doing so.
Developers and their APIs might not be. The user-facing software often does, and it often does not let you switch, at least not without affecting other things (such as the spelling of “colour”).
> There is no justification for it other than the general US contrarian attitude of "you're not the boss of me".
I'm a proponent of the metric system, but that's either a wild straw man or very lazy thinking. An obvious justification (which has lots of merit) is "I've been using imperial all my life and it's what I know, what I think in, etc." Changing systems would be very disruptive for a lot of people. IMHO that doesn't mean we shouldn't do it, but it is something that should at least be acknowledged before a massive forced upheaval of a system.
Just thinking about driving for a minute, even little things like the speedometers in cars being primarily mph, millions of miles of mileposts all around the country that would need removing and changing. Every road sign with miles on it, etc. Those things are a little more than just "you're not the boss of me"
There are more factors of 12 than of 10. This makes some imperial units more practical for certain types of things that involve mental math or quick calculations. Fahrenheit is higher resolution than Celsius for weather/climate measurements.
Never mind American date format, visualize how something like the democratic congressional hearings on TikTok would appear to a super intelligent alien who just arrived here and hasn't had a chance to get his bearings on human culture.
Or, replace the alien with the founding fathers of this formerly great nation, or replace these hearings with most anything we do.
In fact I once nerfed a small database by importing a bunch dates from a csv in the wrong format.
But honestly both formats (M/D/Y and D/M/Y) are wrong, as clear from the clock example: dates should be big-endian; Y/M/D.