Files
hpr-knowledge-base/hpr_transcripts/hpr4609.txt
T

75 lines
6.3 KiB
Plaintext
Raw Normal View History

Episode: 4609
Title: Proper Date Format
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4609/hpr4609.mp3
Transcribed: 2026-07-31 16:15:05 (official HPR transcript)
---
This is Hacker Public Radio Episode 4609, for 2026-04-02
Today's show is entitled, "Proper Date Format"
The host is Ahuka and the duration is 00:07:19
The flag is Clean, and the license is CC-BY-SA
The summary is "There is only one logical date format"
You are listening to a show from the Reserve Q. This show was submitted in February 2025 to cover
occasions like this, where there are gaps in the schedule. Hello, this is Ahuka welcoming you to
Hacker Public Radio and another exciting episode. And this is from the Reserve Q. So this particular
show is what I'm calling proper date format. Now, one of the things you quickly run into if you
correspond with people who are both in the United States and Europe, which I have done both in my
career as well as in my personal life, is that we don't write dates the same way. I know when I was
working as a project manager for Ford, you know, we had operations in Europe. And so many of my
projects, I had to work with people there. And, you know, thing about project management is, you know,
dates and times are extremely important when you're managing a project. And the thing that we ran into,
and, and now, of course, you know, my personal life, I run into it as well, because like, you know,
I'm involved with doing shows for Hacker Public Radio, and that's got people all over the world
listening. So I think we all know how this works. Now, we'll start with March 14th. Now, in the United
States, we like to say March 14th is Pi Day. And why is it Pi Day? Because in the United States, it is written
as 3 slash 14, 314. And we know Pi starts 3.14. So in the United States, that seems like a clever
little thing. Now, people in Europe would look at that and say, why do you think there is a 14th
month to the year? Now, suppose you want to make a joke about May the 4th. Okay, and that's Star Wars
Day, as in May the 4th be with you. In the US, we would write that as 5 slash 4. But in most of
Europe, it would be 4 slash 5. And it can be even more complicated once you drag in the rest of the
world. There is simply no uniformity. You can see it with, there's a page on Wikipedia, I've put a link to
that in the show notes, that basically shows you the date formats for every country in the world.
And it's just, there's no consistency, no uniformity at all. And we're not even consistent in how we talk
about dates. Now, in the United States, we might well say May 4th, as that does indeed match how we
write dates. But then we will insist that our Independence Day is the 4th of July. Almost like
we're not a British colony any longer, but let's use their date format for one of our most important
dates. Now, in my experience, each side thinks the other is a bit odd, but regards it as a harmless
eccentricity. But which side is correct in this? The answer, of course, is neither. The one absolutely
correct date format has been defined, and you can find it in the ISO 8601 standard, and I've put a
link in the show notes if you want to look that one up. The correct date format is four-digit year,
followed by two-digit month, followed by two-digit day, because that puts the elements of the date in
a logical order. Now, why is this the logical order? Well, suppose you were filing documents by date.
Would you start by putting all the documents from the fourth day, without regard to month or year,
into a group? Or would you first collect all documents for a given year?
Now, you might argue that filing documents is something people don't do as much of these days.
We have computers and digital documents. We don't need any stinking filing cabinets.
But that only strengthens my argument, as you can easily verify. For example, I'm writing this on
February 13th, 2025. If I use a date code for my digital file, and I make it 02132025,
what happens if I later create a file on, say, January 6th, 2026? That would then be 01062026.
Try this, and you will see that in your file manager, 01062026 will appear before 02132025,
because all computers treat the significance of digits from left to right. The most significant
always on the left, the least significant always on the right. Also, when you take a look at this,
you see why it is necessary to have two digits for month and day. You say, well, you know,
if I can write May the 4th is 5-4, why do I need 0-5-0-4? Well, try it, and you will discover
that you need that 0 for things to come in the right order. If you don't do that, then you're
going to get things that are going to go 1, 10, 11, 12, 2, 3. It's just, that's what happens.
So, you know, there's a reason for all of these. Now, with the ISO 8601 standard, the most significant
part of the date is on the left, and all of your files will be in order. And once you get used to it,
your life is easier. An example of this is photos. Now, my wife and I like to travel. We're retired,
and we can do that. And we take a lot of photos using our smartphones. And every photo we take
uses date, time stamps as part of the file name. And the dates all follow the ISO 8601 standard.
So, I can easily sort my photos in the order in which they were taken. And since I have over 13,000
photos in my Flickr Pro account, a little help with sorting them is really nice. I now use this
format not just for digital file names, but for most of my dating purposes. It really just makes sense.
And I hope you will also see the sense in this and adopt the ISO 8601 standard. So, this is a hookah
for Hacker Public Radio, signing off, and as always, encouraging you to support free software.
And since this is coming from the reserve queue, I'm also going to encourage you to record a show.
This is a community project, and it will only exist as long as people record shows for it.
So, bye-bye.
You have been listening to the Hacker Public Radio podcast, at hackerpublicradio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, then visit the HPR site to find out how easy it really is.
Hosting for HPR has been kindly provided by anhonesthost.com, the Internet Archive, rsync.net, and the HPR Community Content Delivery Network.
Unless otherwise stated, today's show is released under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.