We're not all in the US: Annual rant about dates
-
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(
-
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(
What about the war between point and comma as decimal/thousand separator? A joke comparing to dates war, but...
-
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
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
-
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
That's the tip of the iceberg. When you start getting to points in time and calculating between different points in time it becomes even more of a pain - then some developer decided to save dates without a timezone because "why would anyone ever need to know the timezone?" Dates are perhaps one of the biggest PITAs in data.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I'm an optimist at heart!
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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....
At least we don't use stones for people, MPH for speed limits while distances are in Km
-
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
Absolutely, I agree. I alwys use '2022-07-03' OR '2022/07/03'. Different separator, same meaning.
-
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
American here. I agree that we need to resolve this date issue to something unambiguous, but I have a question:
Quote:
2022-07-03 is universal. Everyone gets that, even SQL.
... which is yyyy-mm-dd, right? Could/should we say that SQL is siding with the US on this one? I mean ... everyone adapts nicely to SQL dates, right?
-
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
The reason is that habits are hard things to break. :( Americans have fallen into using those things out of long developed habits involving these things. Besides that, the monetary cost of switching to these things, as you are suggesting, would be mind-bogglingy huge. Our economy would go into a depression causing a world-wide depression. So, you see we are doing it for your own good. Just because something is popular, doesn't make it right or good. :-D Lastly, if you all went and jumped off a bridge, killing yourselves, should we do the same? :confused::confused::confused:
Yodles!
-
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....
We were in the process of converting to metric but couldn't figure out how to handle 19" racks. :)
>64 Some days the dragon wins. Suck it up.
-
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
Looks like these days global hunger is not big of a problem anymore.
-
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
Julian dates all the way! 15-Jul-2022 = 2022-196 or 22196. Julian Date Converter - Longpela Expertise[^] I actually worked on an application back in the 90's where dates were tracked as Julian dates. Was a US Air Force transportation system and data records all had to fit in lines of 80 characters. Julian dates saved us one character. :)
-
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
yyyy-MM-dd for dates. But I don't run the USA, or even the world. ISO 8601 I've worked on systems where they've adopted (invented?) MM-dd-yyyy and MM-dd-yy. Emphasis: using dashes, not slashes "MM/dd/yy", nor "dd/mm/YY". I don't think those are used anywhere but in a legacy developer's fanciful invention. It's a nuisance for new work, and it's so baked-in that it's unlikely to ever be fixed. Guaranteed to be incompatible with any country's format (ref Date format by country - Wikipedia[^]
-
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 once had to present dates on an 80-character green screen terminal and chose 03Jul22 as the shortest but most understandable form to all countries.
-
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
**<OldFartWarStory>**I rewrote a part of our application that generated a comma-separated value log for import into Excel. Instead of writing a human-readable date the Excel understand, the previous version wrote an integer. As it turns out, that integer was the number of seconds between January 1, 1900 00:00:00 and today's date at 00:00:00. To make matters worse, the time was a floating point value between 0.0 and 1.0, representing the time of day. After reverse engineering all this crap, I casually mentioned this to the engineer who used the log. He also took over for someone now departed. He told me that he never understood how the date and time values in the log worked, and didn't pay too much attention to them :doh: . I quietly showed him how to format the columns in the Excel spreadsheet as 'Date' and 'Time', and drank my dinner that evening.**</OldFartWarStory>**Software Zen:
delete this;
