In a comment on my recent post about C and concatinating strings, there were some very cool suggestions about ways to handle creating a string full of comma separated values (like a .csv file to open in a spreadsheet).
The always helpful MiaM asked:
“Why slash for dates? ISO 8601 specifies the minus/dash sign :)”
-MiaM
In my posted example, there was a date/time at the start of each entry like this:
2024/10/18,12:30:06,100,0.00,0,0,0,902.0,902.0,928.0, . . .
I recall these log files certainly had date/time in them before I ever touched the code, though I do not recall what the format was back then. In the USA, the standard convention for a date is month/day/year using slashes, such as 10/21/2024.
When I started using the OS-9 operating system on my Radio Shack Color Computer, it would prompt for date/time on startup using a different format — yy/mm/dd:
And yes, that would have caused problems when Y2K came around, but by then we already had updated utilities that allowed four-digit years.
But listing year first seemed “weird and backwards” to me. Folks who started using PC-DOS on an IBM PC got used to it in a more “normal” way, it seems:
At some point, I got used to it, and learned a great reason to putting the year first: sorting! Over the past 28 years, I have taken hundreds of thousands of digital pictures. The default filename on my first camera was:
1031_001.JPG - taken October 31, image 001 of that day.
This was due to the 8 character filename limit that PCs had back then. If they had put the year in, like “103196”, there would only be room for a 2-digit number after it like “10319601”, “10319602”, “10319603”, etc. Considering the lack of memory on that early camera, that might have been fine for most folks. After UPGRADING the storage to 5MB, the camera could take 99 photos before you had to hook it up to a computer via an RS232 serial cable and download the images.
But I digress.
Once long filenames were a thing, I started naming photos with the full date. I could have used “MMDDYYYY_number.jpg” like this:
01011996_001.jpg - first photo taken on 1/1/1996
02011996_001.jpg - first photo taken on 2/1/1996
01011997_001.jpg - first photo taken on 1/1/1997
01011998_001.jpg - first photo taken on 1/1/1998
…but if you sorted those photos by filename, you would not get them in date order:
01011996_001.jpg - first photo taken on 1/1/1996
01011997_001.jpg - first photo taken on 1/1/1997
01011998_001.jpg - first photo taken on 1/1/1998
02011996_001.jpg - first photo taken on 2/1/1996
Above, you can see it shows me a photo from 1996, then 1997, then 1998, then 1996. Placing the year as the first number solves this, and allows files to be grouped by year, then month, then day. (I mean, I know we like “mm/dd/yyyy in the USA, but how often do we want to sort to find “all the files taken in January of any year” beyond looking for birthday or holiday photos, anyway?)
By doing year first, everything sorts as we expect:
19960101_001.jpg - first photo taken on 1/1/1996
19960201_001.jpg - first photo taken on 2/1/1996
19970101_001.jpg - first photo taken on 1/1/1997
19980101_001.jpg - first photo taken on 1/1/1998
Side Note: I gave up on image numbers waybackwhen, and use the format YYYMMDD_HHMMSS.jpg for my photos. See my theme park photos, and my Renaissance festival photos, for an example, though many of the earliest photos may still be in the old MMDD_XXX format. I highly recommend the Mac utility ExifRenamer for renaming photos to various formats.
Anyway . . . MiaM brought up ISO 8601:
It specifies a universal standard for date/time values. This table was copied from the wikipedia page:
Date | 2024-10-21 |
---|---|
Time in UTC | 11:24:56Z T112456Z |
Date and time in UTC | 2024-10-21T11:24:56Z 20241021T112456Z |
Date and time with the offset | 2024-10-20T23:24:56−12:00 UTC−12:00 [refresh] 2024-10-21T11:24:56+00:00 UTC+00:00 [refresh] 2024-10-21T23:24:56+12:00 UTC+12:00 [refresh] |
Week | 2024-W43 |
Week with weekday | 2024-W43‐1 |
Ordinal date | 2024‐295 |
The use of a dash in the year (2024-10-21) versus the slash like we tend to do in the USA would be a simple change. Yet, when I look at Excel, when you select the “short date” format, it defaults to “mm/dd/yyyy” (see image to the right).
I might expect slashes were used so the .csv file could import in to Excel, but Excel doesn’t seem to care. It figures it out. I also now wonder if using this format was intentional, and it may have originally been mm/dd/yyyy to match what Excel defaults to.
Speaking of defaults … in other parts of the world, the date/time format is different (such as dd/mm/year in Europe, which always message me up if the day is 12 or less since I cannot tell if 1/10/2024 is January 10th, or October 1st).
But now that I have been pointed to this standard, I think I am going to try to force myself to adopt the ISO 8601 standard when I start representing dates in software. No doubt, seeing the USA format in the Windows application I maintain may be odd to folks in other parts of the world. If I switch it to use the ISO 8601 standard, it might seem odd to some folks, but at least there is a reason that can be referenced.
The more you know.