We're not all in the US: Annual rant about dates
-
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; -
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
Our dirty secret is we store times as local timezone and we've had an outstanding TODO from about 14 years ago to convert all of them to UTC. Generally pretty easy - just add 5hrs. Except we have to take into account daylight saving. For every year. And then you have to be careful about the boundary times and the order in which you update. And then your head hurts and you look at the other things on your TODO and think "dates work. Let's not stir the hornets' nest"
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
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|
-
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
RooN3y wrote:
But I don't want to blame Linux. Stupid AWS
:laugh:
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:
Yes - I was bitten by that the other week. Garmin, for example, bases its epoch on the day the company was born. I'm not saying they have a alightly skewed notion of their importance in the universe or anything, but...
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?
In my view heirarchical values like dates (or versions, or taxonomies etc) should be ordered in increasing or decreasing order, but never both. So year -> month -> day or day -> month -> year but never, ever, ever month -> day -> year. I don't think SQL is siding with anything other than a format that efficiently sorts. Not that SQL sorts dates based on a string representation...
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. :)
There is a large company I talk with regularly who shall remain unnamed who constantly refer to week numbers when talking dates. But not "week 1 = first week of January", but "week 1 = first week of their financial year". No one understands what they mean except them. It's like a traffic accident. I just watch with my mouth agape.
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.
We use dd-MMM-yy but I still worry it's ambiguous. I played with dd-MMM-'yy to clarify but it just didn't seem right.
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 am stateside, and I really encourage people to use: YYYYMMDD as much as possible. Especially for filename prefixes. it's awesome, because it sorts wonderfully (sequentially), and is unambiguous. Having spent a lifetime with Oracle, I use 03-Jul-22 a LOT, as in code comments, etc. I feel your pain.
-
In my view heirarchical values like dates (or versions, or taxonomies etc) should be ordered in increasing or decreasing order, but never both. So year -> month -> day or day -> month -> year but never, ever, ever month -> day -> year. I don't think SQL is siding with anything other than a format that efficiently sorts. Not that SQL sorts dates based on a string representation...
cheers Chris Maunder
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.