|
|
Looks like these days global hunger is not big of a problem anymore.
|
|
|
|
|
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
|
|
|
|
|
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[^]
|
|
|
|
|
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
|
|
|
|
|
<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 . 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;
|
|
|
|
|
|
Actually he's a sharp guy, he just didn't have a pressing need for the date/time values.
Software Zen: delete this;
|
|
|
|
|
My apologies to your colleague for being presumptuous.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Oh trust me, there are plenty of engineers here who can create documentation in any app you like, as long as it's Excel .
Software Zen: delete this;
|
|
|
|
|
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 ing 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...
MM/DD/YY
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
I think your computer may have the Atari Centipede virus.
Beware of spiders, fleas and scorpions!
|
|
|
|
|
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.
|
|
|
|
|
Chris Maunder wrote: 2022-07-03 is universal. Everyone gets that, even SQL. I couldn't agree more! This is what I use everywhere I have a choice. As someone else already mentioned, the sorting works with no special effort.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Perhaps it's because we're conforming to the international standard, ISO 8601, that uses the format yyyy-mm-dd and we just shortened it to mm-dd.
Of course, it might also be that we just don't care, and people who want to use the web sites we build just have to figure out which of the many nonstandard date/time formats we're using. When we really want to piss you off, we also use the English month names, for no better reason than because the site uses English. So don't push us or we'll switch to the Mayan calendar. Grrrr.
Really, if that's the worst complaint you have about AWS, you are a pretty satisfied customer.
|
|
|
|
|
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!
|
|
|
|
|
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!
|
|
|
|
|
Allowance
for PRO
idea VISION PROVISION
I didn't think that one would last, but I liked it ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
hmmm, not 8 letters long ...
|
|
|
|
|
We will make an allowance for him this time!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Yes there are:
P One
R Two
O Three
V Four
I Five
S Six
I Oopsie
O Seven
N Eight
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Ahh I see. No wonder I never got the hang of the metric system.
|
|
|
|
|
Honestly... Not choosing the O for Oopsie????
|
|
|
|