Decoding a Date String

[paul_cardinale]

---

@GerdW wrote:

Hi Paul,

---

@paul_cardinale wrote:
I don't want to encourage anyone to use dotted formats (for dates and phone numbers).

---

But exactly those are standard in Central Europe! (Well, atleast for dates. Never seen phone numbers using dots.)

Tomorrow is 08.07.2022 for me…

With a big grin: when asking a worldwide forum for opinions you should not reject worldwide suggestions because of an US point of view… 😄

---

I don't think it's a US point of view (it's here in the US that I sometimes come across dotted phone numbers).

[paul_cardinale]

---

@crossrulz wrote:

---

@Frozen wrote:

---

@GerdW wrote:

Hi Paul,

---

@paul_cardinale wrote:
I don't want to encourage anyone to use dotted formats (for dates and phone numbers).

---

But exactly those are standard in Central Europe! (Well, atleast for dates. Never seen phone numbers using dots.)

Tomorrow is 08.07.2022 for me…

With a big grin: when asking a worldwide forum for opinions you should not reject worldwide suggestions because of an US point of view… 😄

---

---

NOTE: The following comment is entirely tongue-in-cheek

Yeah, but as an American, I feel obliged to not care

On a more serious note, I do prefer YYYY-MM-DD because it makes sorting a lot easier.

---

Sometimes when I want both sortability and readability, I use %Y-%m (%b)-%d which yields 2022-07 (Jul)-07 for today.

[AeroSoul]

---

@paul_cardinale wrote:

---

I don't want to encourage anyone to use dotted formats (for dates and phone numbers).

---

In my country (central EU) we use dotted format dd.mm.yy(yy), using slashes or any other format is very uncommon.

Phone numbers are written with spaces every 2-4 numbers, depends on if it's a landline or mobile.

eg.: landline: 01 234 5678

       mobile:  012 345 678

Long numbers likewise don't use dots to separate thousands, but most often spaces (or nothing) and we use comma for decimal values.

[wiebe@CARYA]

You simply can't convert any date string to a date without error, based on just the string. As mentioned, there's simply no(t always a) way to distinguish months and days...

However, if you know the origin of the string it can be easier. If the string comes from the system (for instance, IIRC Access returns dates in system formatting) you can use this. Simply convert a time to string and parse the string to see where the input month, day, year ended up...

I know I did (had to do) this a few times long ago... It's never going to be tight.