We're not all in the US: Annual rant about dates
-
At least we don't use stones for people, MPH for speed limits while distances are in Km
Where's that? Here in the UK, road sign distances are in miles and speed limits are in MPH.
-
Feel your pain with AWS. We have to set the culture code at the start of every Lambda we have because our main website sends dates in the british dd/mm/yyyy format and lambdas default to US format regardless of the region. The first 2 weeks of January where fun! I'm blaming AWS but to be honest it's probably the Linux image they use to spin up the lambda. But I don't want to blame Linux. Stupid AWS
-
Chris Maunder wrote:
Can we please, each of us, take a quick look at our code and maybe, just maybe, rethink how dates are presented.
I've done this numerous times, and always reached similar conclusions to yours. The problem is ignoranus :elephant:ing :sunshine: clients, who refuse to acknowledge the existence of users from outside the US (in rare cases this has actually been a valid assumption) and insist on formatting it at 07/03 because that's the way they learned while snacking on crayons and paint chips, and anything else is too confusing or too hard or too weird or too... X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X|
-
Remember, this is the same country that is still using the English system of measures, when almost everywhere else we use the Metric system... It is as if there is a need to proclaim that they are not like anyone else, all the time....
To correct your misunderstanding of the US, we do (and have) used both English and metric. I, like other kids of my generation, learned both in high school back in the 1960s. And I was raised in a small town/rural area. Americans really have no issue using both and switching between them.
-
S0, for July 3, 07/03 is okay by this standard, though 07/03/2022 would not be? Or 22/07/03 would work? As you suggested, maybe numbers should never be used for months in scheduling, because changing decades-old conventions never ends in anything but confusion. Jul3,22 | 3Jul,22 | 3Jul22 - none of these will end in confusion.
Yeah but the great thing with standards and conventions are that there are so many to choose from.
cheers Chris Maunder
-
To correct your misunderstanding of the US, we do (and have) used both English and metric. I, like other kids of my generation, learned both in high school back in the 1960s. And I was raised in a small town/rural area. Americans really have no issue using both and switching between them.
Actually, it all depends on what of the country you look at. I have lived and worked in the US, and have experienced this for myself. While I agree that the Metric system is taught (to some degree, again depending in what state yih are in), I have yet to see road signs in anything other than Miles or MPH. Or fluid measures - especially when the US usesUS gallons VS. Imperial gallons. Or weights. And so on. This isn't to say that metric measures aren't used in the US. At least in the scientific community they have embraced the Metric system as it is provides a consistent base with the rest if the scientific community. But as far as the average daily usage in America, I have yet to see it take hold. I am not looking to start a flame war with this. This is simply my own experiences and observations. I also admit that there are still some holdback's to the English system - specifically we still use acres instead of hectares. That would be more difficult to change and use as it would impact how to describe land usage (a fraction of a hectare vs. one acre). But for the most part we here in Canada have made the switch back in the 70s, and have pretty much given up on the English system with no regrets.
-
I feel your pain. Since a long time, I am using the
3 Jul 2022format."In testa che avete, Signor di Ceprano?" -- Rigoletto
Why not make it crystal clear and use the ISO format 2022-07-03. Not possible to make mistakes reading it and as far as computer goes, this format sorts just perfectly fine...
-
Visit Canada and you'll be disabused of the notion that the rest of the West hasn't allowed the insane to take over. Or New Zealand or Australia, for that matter. And that's not even mentioning the EU, which is almost beyond hope.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Sounds like a US of A caveman...
-
Remember, this is the same country that is still using the English system of measures, when almost everywhere else we use the Metric system... It is as if there is a need to proclaim that they are not like anyone else, all the time....
Back to the Stone Age! Fred Flintstones units forever! LOL
-
Why is it that so many sites - the latest being AWS's portal - refuse to understand that the only country in the world that uses MM/DD as a date format is the US. OK, and Belize. And Canadians when they are being accomodating and polite. But no one else. The rest of the world is looking at 07/03 thinking "7th of March?". I honestly don't understand why companies do this other than they straight out don't realise no one else does does dates like this. I've banned ambiguous dates at CodeProject and DeveloperMedia because when we need to get dates nailed down and the conversation includes an American, a Canadian and an Australian (not walking into a bar) the conversation falls apart quickly if we can't trust the date that's been written on the contract. Can we please, each of us, take a quick look at our code and maybe, just maybe, rethink how dates are presented. Here are some options: - IF you're tight on space then 3Jul is better than 03/07 and 07/03. And sure, we then run into language issues, but if your site is predominately english then your readers have far bigger issues. - 2022-07-03 is universal. Everyone gets that, even SQL. - 3-Jul-2022 is friendly and obvious. 3-Jul-'22 is shorter if you really need s pace. - 1656806400000 is accurate, unambiguous, precise to the millisecond. And fairly useless. Don't do this.
cheers Chris Maunder
Totally agree! Not only is plain wrong (in my opinion), but is also sooo confusing in many instances. Never mind the arrogance! And speaking of time, it makes the hair stand up on the back of my neck every time I hear the morons speaking of hundreds of hours (never something like 1745 hours!). Is there any other country in the world where the people are so handicaped so they cannot handle numbers up to 24?! And to understand that 17:00 is not 1700, but hours and minutes?! I understand their obsession for war, but nowhere else in the world, when people look at a clock, automatically think of 'military'... Another issue I have to deal with quite often: paper formats. I own a printer made in Japan and sold in Europe, which for the love of God, refuses to understand that letter format (for example) is something I NEVER need. That is the default! In Europe. Coming from Japan! WHY? And, of course, there is no way to set another format (like A4) as the default! Incomprehensible!
-
Why is it that so many sites - the latest being AWS's portal - refuse to understand that the only country in the world that uses MM/DD as a date format is the US. OK, and Belize. And Canadians when they are being accomodating and polite. But no one else. The rest of the world is looking at 07/03 thinking "7th of March?". I honestly don't understand why companies do this other than they straight out don't realise no one else does does dates like this. I've banned ambiguous dates at CodeProject and DeveloperMedia because when we need to get dates nailed down and the conversation includes an American, a Canadian and an Australian (not walking into a bar) the conversation falls apart quickly if we can't trust the date that's been written on the contract. Can we please, each of us, take a quick look at our code and maybe, just maybe, rethink how dates are presented. Here are some options: - IF you're tight on space then 3Jul is better than 03/07 and 07/03. And sure, we then run into language issues, but if your site is predominately english then your readers have far bigger issues. - 2022-07-03 is universal. Everyone gets that, even SQL. - 3-Jul-2022 is friendly and obvious. 3-Jul-'22 is shorter if you really need s pace. - 1656806400000 is accurate, unambiguous, precise to the millisecond. And fairly useless. Don't do this.
cheers Chris Maunder
Another thought on this… Since Y2K, 4 digit years are standard. Programmers should start coding all months as THREE digits! 2022-007-18 007/18/2022 18/007/2022 Start with CodeProject.com… Solved!
-
Visit Canada and you'll be disabused of the notion that the rest of the West hasn't allowed the insane to take over. Or New Zealand or Australia, for that matter. And that's not even mentioning the EU, which is almost beyond hope.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.It's everywhere:- [https://www.amazon.com/Cynical-Theories-Scholarship-Everything-Everybody/dp/B08LDSWJ9V/ref=sr\_1\_1?crid=22HDZKA1DOBYH&keywords=Cynical+Theory&qid=1658183760&s=books&sprefix=cynical+theory%2Cstripbooks%2C297&sr=1-1\](https://www.amazon.com/Cynical-Theories-Scholarship-Everything-Everybody/dp/B08LDSWJ9V/ref=sr\_1\_1?crid=22HDZKA1DOBYH&keywords=Cynical+Theory&qid=1658183760&s=books&sprefix=cynical+theory%2Cstripbooks%2C297&sr=1-1)
