|
I have no idea why. We nearly changed to Celsius from Fahrenheit about 35 years ago, but to no avail.
I will admit, recently traveling abroad, I nearly entered my DOB as mm/dd/yyyy instead of dd/mm/yyyy for the custom's arrival and departure cards. Luckily my programming instincts kicked in and I made it through without incident.
|
|
|
|
|
Come on Chris, everyone in the world knows that Americans don't care what other countries have to endure, as long as we make money pushing out crap to ya'll.
Runs for cover...
|
|
|
|
|
Well, how come you don't ship outside the States then? He did ask! It does seem to be a wasted opportunity to grab bundles of cash from us! Oh, the t-shirts I'd buy! 
I am not a number. I am a ... no, wait!
|
|
|
|
|
Totally agree. It can be argued that dd/mm/yyyy is also ambiguous, but at least the parts of the date are sorted in a meaningful way. Expressing a date in the format mm/dd/yy is like a car salesman telling you that this SUV you're looking at will cost 999 $, 99 cents, and 24 thousand $. 
The problem I see with any of the aother alternate formats is that either the position of days and months is still ambiguous, or the month is expressed as a name or shortcut thereof, which adds a language-dependend component. Neither is great for international use so I prefer yyyy-mm-dd. At least that one can be sorted. And it works for car salesmen too 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I'd like to response with another question. Imagine that you have international project with 20 countries involved, but 90% of your income is generated by USA customers. Which format you will choose? USA or Canadian?
Another use case, imagine, that initially all your customers where from USA and only in two years after launching your product, you got those customers in other countries. What as usually customers ask: change format of dates or some other feature. From my experience issue with dates formatting was in backlog, but as usually it is not in high priority.
|
|
|
|
|
witnes wrote: Which format you will choose? USA or Canadian?
Neither. That's what Locale is for. If only 10% of your revenue comes from people outside the US it's time you spend more effort making foreign customers comfortable.
That said, I'm not american - leave it in US format for all I care
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
witnes wrote: Imagine that you have international project with 20 countries involved
Although it was only a couple of countries, my mind turns towards the Hubble telescope. Oops!
|
|
|
|
|
Some years ago one of the departments in our US based company created a new international telephone directory. This contained all the phone numbers of our offices, and agents, worldwide. So it needed to prefix the numbers with the country code. But just to be helpful they included the IDD prefix also, so every number listed had the US IDD prefix 011-xx-xxx-xxxxxx. And whenever one tried to explain that certain Americanisms did not work or make sense in other countries, the response was always, "Thank you for your concern, we will take it under advisement".
|
|
|
|
|
Having worked in the US, Canada and Europe I have similar experiences with the date format used by Americans and Canadians (sometimes, when it suits) I ended up adopting my own format which is unambiguous, easy, needs no spaces or punctuation, easily parsed and, to me at least, makes sense - ddmmmyy where mmm is the first three letters of the month 11Nov16, 09Sep14 etc and without explanation or reference it should be immediately understood by everyone (except maybe them Canadian Frenchies who would pretend not to understand it as a matter of principle)
|
|
|
|
|
American way of date has its historic roots, but nobody forces 'em to pull such sht in IT! Moreover - why to use digits at all?! Even their idiotic date format can be human readable if it was "May/4/2016"! But they are too dumb and conservative to use progress. They invented computers... just to sell hotdogs faster!
|
|
|
|
|
You have a couple similar cases, especially in web stores which use software developed in the US, even though they are European stores:
Lots of European countries put the ZIP code ahead of the city name, not after the state name, but the address label print routine insists on doing it "The American Way".
In Europe, there is a standard for prefixing the zip with a country code (like NO-7035 Trondheim here in Norway). Lots of web stores will not accept this format.
If the web store requires a telephone number, I would follow the international standard of adding a prefix "+" and the country code, like "+47" for Norway - the plus sign indicating "Whatever prefix your national telephone system requires for international calls". Lots of web stores refuse to accept the +.
In several web stores, I have to repeat either the city name or the country name, because the software insists on a "State" level inbetween.
I have even bought stuff from stores insisting on a non-empty "county" name (in addition to the "state" name). Sure, we do have county names in Norway, but they are never used in addressing!
However, my biggest frustration has nothing to do with European vs. US style: I have never, ever, had my credit card number accepted the way it is printed on the card: As four groups of four digits! Every single web shop insist on a single 16-digit sequence, which is far more difficult to verify against your card. It would take the programmer one single one-line function call to remove the spaces from a four-times-four digit enty, but not one of them will do that!
Usually, the same applies to telephone numbers: You cannot type them the way you normally do, in space or hyphen separated groups of digits. Maybe one in four will allow spaces/hyphens, serving as a proof that it is possible to remove them programmatically....
|
|
|
|
|
I always program my software to accept such normal usages of common numbers. I have never understood why other programmers can't seem to do that.
|
|
|
|
|
Amazing that you're not railing against the focus on Arabic numerals; what about all of those people in the international community that use alternative counting systems? Or other-than-lunar calendars? How, in this day and age, are we overlooking the people that believe that time as it is understood is meaningless, and express the date as "today". 
Honestly, though, I'm more curious as you why anyone in their right mind would think that dd/mm is better. It has all the same problems, is equally stupid, and is just as reliant on cultural knowledge. If we're going to reformat, I hope it would be to ddMMMyyyy to bludgeon understanding into people (that do believe in time, anyway).
In the end, though, I will not have an agenda of changing the common cultural norm (I'm just not that invested) so I'm going to go with the old row: "It ain't broke, so I'm not going to fix it."
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: Or other-than-lunar calendars?
Other than?
The Western calendar is NOT a lunar calendar. I was working on a project with some Korean people, where they (at least partly) use a real lunar calendar. They count years not by 365.24 days but by 12 full moons. Furthermore, they tell their year by the year you are in: A baby's age is 1 year the first twelve months of his living. As soon as he starts on his second (moon) year of living, his age is two - actually, he turns two a few days before we would say that he turns one!
So when I asked the age of one of these Koreans, it had to be calculated: First, correcting from "1 origin" to "0 origin", then multiplying the number of days difference between the moon year and the sun year, and subtract from the moon year age ... This is so long ago that we didn't have smartphone apps to convert it; I guess that today we have it.
Disclaimer: This is what a small group of Koreans told me. There may be different subcultures, and today, twenty years later, maybe the Western calender has taken over everything dollar business related. Yet I wouldn't be surprised if the old calendar survives in private activities, like celebrating anniversaries etc.
|
|
|
|
|
Nathan Minier wrote: Or other-than-lunar calendars?
Other than?
The Western calendar is NOT a lunar calendar. I was working on a project with some Korean people, where they (at least partly) use a real lunar calendar. They count years not by 365.24 days but by 12 full moons. Furthermore, they tell their year by the year you are in: A baby's age is 1 year the first twelve months of his living. As soon as he starts on his second (moon) year of living, his age is two - actually, he turns two a few days before we would say that he turns one!
So when I asked the age of one of these Koreans, it had to be calculated: First, correcting from "1 origin" to "0 origin", then multiplying the number of days difference between the moon year and the sun year, and subtract from the moon year age ... This is so long ago that we didn't have smartphone apps to convert it; I guess that today we have it.
Disclaimer: This is what a small group of Koreans told me. There may be different subcultures, and today, twenty years later, maybe the Western calender has taken over everything dollar business related. Yet I wouldn't be surprised if the old calendar survives in private activities, like celebrating anniversaries etc.
|
|
|
|
|
I'm American and I have made no secret of my disdain for mm/dd/yy to friends and co-workers and the problems it causes.
In software I always use dates of yyyy/MM/dd or MMM dd, yyyy so there is never ambiguity.
|
|
|
|
|
Working for the Navy for 20+ years, I always refer to dates as DAY-MONTH-YEAR, but I write out (or speak) the month to avoid ambiguity. So 26 May 2016, not 26/5/2016 or 5/26/2015. Or in true Naval Message Traffic style, 26MAY16. Be the change you want to see.
|
|
|
|
|
I prefer "dd-MMM-yyyy" ("26-May-2016") so that everyone, everywhere understands what you mean. (and before you say "well, everyone who speaks ENGLISH!!..hee hee" Yeah, well, the rest of the page is in English too, ...)
Truth,
James
|
|
|
|
|
The major disadvantage is that month names are language sensitive.
|
|
|
|
|
As I said, the rest of the page is in English too...
Truth,
James
|
|
|
|
|
I usually use yyyy-mm-dd, except when my audience can't figure out simple things. Not only is it efficient to sort by date, but, if I am unsure about the date, I leave off the day (yyyy-mm) very simply, and it is clear that I am using yyyy-mm-dd, because no one that I know of would use yyyy-dd-mm, so the format is always clearly understood. Even computers understand it.
|
|
|
|
|
Sadly, if/when Americans start to use YYYY-MM-DD (like my country's actual Canadian Standard) - I suspect some people around the world will start to use YYYY-DD-MM just because they refuse to do anything the way American's do.
peter horwood aka Madman Pierre, VP Development, Asset Pro Solutions Inc.
|
|
|
|
|
Actually, a lot of us in business in Canada use YYYY/MM/DD for our business and personal affairs.
Indeed, it is the CSA (Canadian Standard's Association) standard since the 1980's, and almost all government forms etc.., in Canada use YYYY/MM/DD. We started to made the switch in the 1980's due to the upcoming millennium and basically to get rid of all the stupid problems between 9/11/xxxx 11/9/xxxx etc..,
And yes, when our dealings are primarily with Americans, we use mm/dd/yyyy because it is more profitable to do so, and your other reasons for us using the American method are true too.
And yes, most Canadians, if the form doesn't spell it out, use dd/mm/yyyy.
Fortunately, no Canadians are confused when those of us that use yyyy/mm/dd write out a date(Though using yy/mm/dd still causes problems and will until 32/1/1
Unlike what I suspect is 'political comment' in some of the other replies, my following is not: I think it is a tragedy when anyone is killed regardless of their country of origin, religion or skin colour. However, I always had trouble remembering what the most common NON-standard in Canada (my country) was until '9/11'. Because the phrase 9/11 lets me remember that Americans use mm/dd. So now, whenever I'm trying to read a date from a Canadian or American that is not in our CSA format, I just remember '9/11' and then I know which non-standard they are likely using.
>And I don't know how their brains don't explode.
And our brains don't explode because we easily understand both formats (we just have no idea which it is when the day is < 12 and worse when the year is less than 31 AND the day is < 12)
mm/dd/yyyy is the way it is spoken in English: "April 1st, 2051"
dd/mm/yyyy is mathematically logical: "least important to most important"
yyyy/mm/dd is the obvious 'you can't make it confusing'.
And yes I realize if Americans ever changed to yyyy/mm/dd some people somewhere would probably decide to use yyyy/dd/mm just so they don't do it the way the Americans do it. But I suspect/hope rational heads would prevail. I've only once see a company use yyyy/dd/mm and they switched within days of doing that.
peter horwood aka Madman Pierre, VP Development, Asset Pro Solutions Inc.
|
|
|
|
|
Quote: mm/dd/yyyy is the way it is spoken in English: "April 1st, 2051"
Actually, it's the way Americans say it. Apparently, European English speakers would say "The 1st of April, 2051".
Truth,
James
|
|
|
|
|
Wouldn't that be the Calends of April?
_______________________________________________________________
Ah don't lean on me man, cause you can't afford the ticket
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
