Yes, when receiving a date as a string, then what you say is correct that you will need to know the format. But that is going to be an issue no matter what nodes you have.
But once we have got the date held internally as a Date, you are in full control, and any conversions can be made very easily because you no longer need to worry about regional formats…
When a date is actually held as a Date datatype (e.g. LocalDate), there is no such thing as “date format”. It doesn’t matter which part of the world you are in, what your system locale or region is set to, as internally a date datatype is held the same way.
Dates do not have any format of their own, which is often why on the forum people mistakenly ask “how can I change to format of a date”, when what they mean is “how can I change the way the system visually displays the date”. Its a subtle but important distinction.
It is only when you attempt to visually represent a date, that a decision about the display format is made. But that is nothing to do with the date.
So if you have a column LocalDate and you elect to convert it to a String using Date&Time to String, you can specify whatever format you wish e.g. yyyyMMddHHmmss, and then when you use String to Date&Time, you tell it the same format yyyyMMddHHmmss and tell it you just want the time part, and it will work no matter what your region or other settings are.
Regarding a “date&time format analyzer”, there is only so far that can go. If dates have a day number exceeding 12, and a 2 digit year exceeds 31, it can kind of work,
e.g. “01-13-32” is clearly in mm-dd-yy format, and 14-03-2023 is clearly dd-mm-yyyy format
but “01-02-03” is ambiguous, as is 12-03-2023, and so such an analyzer can still make wrong guesses, albeit this improves with a larger data set.
I think that the existing date/time nodes could be considerably improved in the way they parse dates though, as at the moment they are far too rigid. Java allows dates to be parsed with less strict rules, if the options are set (case-insensitive for example: who cares if we write “Jan” or “JAN” in our date string or whether we use AM/PM or am/pm. It is “obvious” what we mean yet it causes problems all the time!)
I did some work on producing a simple date parsing component, which can make a pretty good stab at interpreting some date strings in very loose formats, so it demonstrates that better parsing capabilities are achievable relatively easily
Here though, because of the potential for ambiguity as in the examples I gave above, it is necessary for the component to be given a hint (it is told which ordering to expect D-M-Y, Y-M-D, Y-D-M or M-D-Y) and whether the time portion (if present) is after the date. (There are a few things yet to be implemented. e.g. that bit about the position of the time - it currently doesn’t have the code for handling the time appearing before the date. I haven’t got round to implementing that, but it makes for a demonstration, and does a job, if I need it)
Sorry I’m getting way off your original topic!
)
