Coped from No outputs activating - #17 by thermonuclearwaifuisation
If post #18 was made in July 23 then how can post #19 a few minutes ago be "5 months later" ?
14m references your viewing.
5mo references July 23, 2024 (not 2023). Hover your pointer over JUL23.
Thank you for the explanation
Personally I think that Jul 23 is a daft way to refer to the 23rd of July, but it does explain what I am seeing
As to the 14m, it seems to relate to the time since posting, which does make sense
That's the Americanization of Discord. MMDDYYYY rather than the way Shiva intended YYYYMMDD (which puts all files in chrono order).
I assume that you mean Discourse, but I do understand the origin of the data representation
Is there anywhere in the World that uses YYYYMMDD I wonder ?
Yes, and it was delightful.
Heh. I agree.
I doubt anyone uses that specific format as it is not very human friendly. Better is the alternative ISO-8601 standard format YYYY-MM-DD.
There is some information on the subject here:
It isn't necessarily a straightforward answer because use of an ISO-8601-compliant format may have been specified officially, but illogical formats might still be in common use.
I set my locale to en-CA in software settings to get YYYY-MM-DD format with English language (but unfortunately Discourse does not have such an option).
I agree as it's not clear if that refers to the 23rd of july or July 2023.
However the forum software will spell out a full year (2023) if the date is not in the current year.
Let's not talk about a date like 03/04 (with a year embedded sonewhere). Is that the fourth of March or the third of April? For me it would be the former.
That makes it even more absurd to ever display it as Jul 23
That's March of 2004.
It makes sense to me. Full year so you can't confuse it with month and day in the current year.
So why not always display the full year, or even better display the full date ?
That you have to ask Discourse or Arduino 
YYYYMMDD is the only logical filename format to avoid when the OS changes the creation date when the file is "touch"ed. Many have called me "not very human friendly" but it (the file naming, not my feelings) makes complete sense to me.
1 Like
YYYY-MM-DD is equally as logical.
Some OS do not allow the "en" or "em" dash and change it to an underscore. Less is more.
Who said anything about en or en dash? A hyphen is used.
Since you have such strong feelings on this subject (as do I), I recommend you educate yourself on ISO 8601 (as I have done).
Honestly, I came to my conclusion in my own, lazy way. My pick for YYYYMMDD without ISO 8601 hyphen (I read your reference just now) or underscore is because I needed to move data among systems (VAX, Unix, MSdos, MAC, Linux), and each system had a problem with another system's use of special characters in filenames. When I arrived at one job site, operators were batch-renaming filenames every day to move to a different system. I showed them how my laziness of using YYYYMMDD could save hours of work... making myself redundant because operations didn't need to stay late any more. This was in the day of 2400 baud handling most of the data because not everyone had 9600 equipment. I also have a story of script translating single-byte data to double-byte data so Japan could use their three written languages to pay their federal employees, but that company, also, doesn't exist any more. My history is full of my lazy work causing the savings of hundreds of hours of work a week and making myself redundant. Now I am a novice again. I know, comparatively, nothing, and I like it. It was nice to read the ISO. It made my day.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.