We're not all in the US: Annual rant about dates
-
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
Insularity, much like the State Department's map featuring "Here be dragons" almost everywhere outside the US.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Insularity, much like the State Department's map featuring "Here be dragons" almost everywhere outside the US.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.That's wrong?
-
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
Confused American: There are "other countries??!"
Happiness will never come to those who fail to appreciate what they already have. -Anon
-
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
ISO 8601 is the only true path. P.S. Do the Gerpeople still use 3.VII.2022 ?
-
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
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....
-
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....
-
Insularity, much like the State Department's map featuring "Here be dragons" almost everywhere outside the US.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
the State Department's map featuring "Here be dragons"
At least the rest of the Western world hasn't (yet) allowed the insane to take over the asylum. One of the reasons that I refuse to visit the US any more is that with all the "woke-ism" and other nonsense, no one (including the locals) knows what the proper standards of behavior are any more. I say nothing of the physical danger of going into many (most?) major cities.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
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
In comments, I have long used yyyy-MMM-dd format (e.g. 2022-Jul-14). When dating documents, I use dd-MMM-yyyy (e.g. 14-Jul-2022). When storing dates (e.g. in a database) I store UT, converting from the current time zone when necessary. When displaying dates in a program, I use the current locale, converting from UT to the local time zone. This doesn't solve all issues - conversion between time zones can be problematic, but is "good enough" for most of my needs.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Greg Utas wrote:
the State Department's map featuring "Here be dragons"
At least the rest of the Western world hasn't (yet) allowed the insane to take over the asylum. One of the reasons that I refuse to visit the US any more is that with all the "woke-ism" and other nonsense, no one (including the locals) knows what the proper standards of behavior are any more. I say nothing of the physical danger of going into many (most?) major cities.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
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. -
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.Well, there are still plenty of places in Israel that I haven't visited yet... :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
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
For Chris Maunder: And now for something completely different (Monty Python). Are there any rules or restraints to posting code (C code) we have written? It's pretty short maybe 3 routines. I am the author of code but make references to the inspiration for it (all in the comments).
"A little time, a little trouble, your better day" Badfinger
-
For Chris Maunder: And now for something completely different (Monty Python). Are there any rules or restraints to posting code (C code) we have written? It's pretty short maybe 3 routines. I am the author of code but make references to the inspiration for it (all in the comments).
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
Are there any rules or restraints to posting code
If it's yours, if you have the right to post it, if you feel it will be of value to someone, somewhere, then go for it! If it's small and is just a "here's how to do x' then maybe post it as a Tip rather than an Article (though either is fine)
cheers Chris Maunder
-
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
Easiest answer: move to the states! (Now might not be a good time, though.)
Our Forgotten Astronomy | Object Oriented Programming with C++
-
Easiest answer: move to the states! (Now might not be a good time, though.)
Our Forgotten Astronomy | Object Oriented Programming with C++
Or leave the US (either solution works... :) )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Or leave the US (either solution works... :) )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Not for his problem...
Our Forgotten Astronomy | Object Oriented Programming with C++
-
jmaida wrote:
Are there any rules or restraints to posting code
If it's yours, if you have the right to post it, if you feel it will be of value to someone, somewhere, then go for it! If it's small and is just a "here's how to do x' then maybe post it as a Tip rather than an Article (though either is fine)
cheers Chris Maunder
-
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
-
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
I was under the impression that epoch dates were unambiguous until I came across those that weren't. Apparently there are so many different versions of those too :sigh: [Epoch (computing) - Wikipedia](https://en.wikipedia.org/wiki/Epoch\_(computing)) On a side note, "rationale for selection" on that page is blank for Unix epoch. I guess someone just pulled that year out of you-know-where :rolleyes:
-
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. -
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
As I've said elsewhere hereabouts - in over 40 years of writing software, the handling of dates has been the biggest single problem I have had to tackle. It's staggering that after all these years, date handling is still a (mostly lost, incorrect and misunderstood) black art to almost all software systems, including date handling libraries, developer frameworks and just about every piece of end user software and web page you come across. 8(
