Because of this post, I just went and checked my ID. All-numeric dates only:
Driver’s licence: YYYY/MM/DD.
Health card: YYYY-MM-DD.
Date on back of Presto card (Southern Ontario regional rail and bus card): DD/MM/YYYY or MM/DD/YYYY (not sure which).
The expiry dates on various bank cards, credit cards, etc: MM/YY (this might be some kind of banking-industry standard).
:: might as well keep cleaning out my bag ::
Expired Mensa club card: DD/MM/YYYY or MM/DD/YYYY (again, not sure which; it’s 01/01/YYYY).
Old bus transfer: MM-DD-YY. Come on, transit system, you know better than that, especially since you recently put in that whole new on-demand trip reservation and app-based fare payment system. At least you’re using the 24-hour clock.
Pay stub: MM-DD-YYYY. This is the automotive industry, which tends to be very US-influenced. On the other hand, the company is worldwide and not based in the States. On the third hand, the place I actually work is local and got bought up years ago, so how integrated it is with Corporate is any guess…
Currently, only about 7% of American adults ever served in the military, compared to 18% in 1980. And, other than active/former military, and a few other fields which use 24-hour time, most Americans rarely, if ever, get exposed to that time format enough to get familiar with it. Nor do most Americans understand UTC, or how to convert UTC to what their local time is.
How does the military explain the 24 hour clock/ military time? The young people joining will presumably not be used to it.
I usually just tell people to subtract 12 from any time larger than 12 and add pm.
The guy, a few weeks ago, having a meeting at 1300, thought he should be there at 3 pm.
COBOL (first implementations in December 1959) specified system date as YYMMDD format. (No century part; they weren’t expecting their programs to last more than 2 generations.)
I’ve used ISO 8601 for quite a few years. As I recall, broadly, it’s CCYYMMDDTHHMMSS.SSS… where the “T” is literally an uppercase “T”, suggesting “time”, to delimit the date from the tod portions. It’s arbitrarily accurate. The standard also covers durations (such as one hour) and intervals (such as the specific period between one datetime and another). And it allows for including the time zone. You can include dashes CCYY-MM-DD and colons HH:MM:SS.
I hope I’m getting these details right, but it’s easy to look up.
One thing I’ve done a lot of is industrial experiments where we might run for days or even weeks, and might care about a fraction of a second. It’s a huge help.
Buried in the line of letters and numbers at the bottom of the ID page of my passport is my birthdate in YYMMDD format. The actual expiry date of the passport is listed as “23 JAN / JAN 24”. The month is “January” or “janvier”, in English and French, as is made clearer by my birth date where the month names are different in the two languages.
Note to self: must renew passport.
Is there an international standard for the formatting of passport data?
Do US passports have French on them? Up until 100 years or so ago, it was an important diplomatic language even among non-Frenchies, so I’m wondering whether there might be a holdover of that in places that don’t use the French language officially.
On my US Passport it looks like the fields are labeled in English/French/Spanish(?)
The dates are DD MON YYYY – for the date if issue the “A” in “MAY” looks to have a star (rather than just a triangle) fo0r the upper part of the “A”
Yes, in mine the dates in the main part are DD MON/MON YY. The only reason I’m sure of that is that the issue date of ten years ago is listed as 23 JAN / JAN 14.
So to return to the OP, I could see where that might cause an issue. Is the expiry date of “23 Jan 24” 2024-01-23 or 2023-01-24? That would determine whether I could get on an international flight right now!
That’s the only part of ISO 8601 I don’t like. That “T” in the middle of a string like “2023-09-24T14:30:00” is really ugly. I wish they had used a punctuation mark, maybe semicolon or tilde: “2023-09-24;14:30:00”.
If the T is used nowhere else in the standard, then it would essentially be a punctuation mark. But yes… it’s ugly.
I could see the semicolon being a problem—too easily confused with the colon. Also, wasn’t the semicolon used in NTSC time codes when frames are skipped?
Edit: yes, sort of. The semicolon separates seconds and frames.
I can’t say for absolute certain that this has cost me time, and thus my employer money, but one of our clients has operations in South Africa, and when working on their audit I have to be vigilant about interpreting the dates that I see in their records, such that it’s almost certain that I would spend less time, if only a few seconds, working on the audit if the date format was the same in both sets of records.
The worst part is that the records for the SA entity are in QuickBooks Online the same as the US entity, but the SA QBO online uses a different date format than the US QBO. I wish there was a way to log into their QBO file from US QBO, but that’s not how Intuit has set up QBO to operate. They have a SA QBO file, so I have to log in through SA QBO, including a different login than the one I use for US QBO.
I was flying from NL to the US to visit friends, and I was bringing some tulip bulbs as a gift. Of course, the tulip bulbs were purchased in a shop that had all the necessary permits to sell stuff to be taken to the US, and each bulb package had a sticker saying that the phytosanitary inspection had been carried out, and the date until which it was valid.
My trip was in August, and the inspection of that package of bulbs was valid until October 1st of the same year. It was written numerically as “01/10”.
The customs officer in the US saw that and refused to let me get the package into the country. No explanation would sway them – to them, that date meant that the inspection was valid only until the 10th of January of the year, and that was waaaay in the past.
And I could not bring the bulbs into the US. Nothing to do there.
But yes… it’s ugly.