Scan From String - Timestamp format - bug and workaround

[JÞB]

Oh, definitely use trim whitespace!  Since, if your ISO 8601 datetime string contains whitespace it is not "well formated." Whitespace is not allowed.

On another point.  There really is no built in ISO 8601 DATETIME parser and it might be worth the effort to build one that would parse the options such as hhmm,mmm+hh,h etc... and stick it in your reuse repo.  Personally,  I just don't really like the limitations of that standard since I like "Friday"

[DavidBoyd]

Further testing seems to indicate that the shortcoming, so far as it can be called that, involves the use of <embedded time formatting>.  If I just use a raw %T, and provide some input in my default Windows time and date format (using my example data formatted thusly):

11:15:23\s07/29/2022

...it is parsed correctly.  And if it includes leading whitespace:

\s\s\s11:15:23\s07/29/2022

...it is still parsed correctly.  So perhaps the additional processing of a custom date/time format is where the issue lies.

And, JÞB, I'd argue semantics here - the datetime string is well formatted within itself, much as a number formatted like 1.234e+06 is "well formatted".  White space before or after (not embedded within!) is acceptable when parsing all the other datatypes.

Dave

[JÞB]

My point being, ISO 8601 forbids whitespace in its string values so, if there is whitespace, it is not well formated.  Just as if the day of month preceded the month or if the Time portion contained a meridian flag it would fail to meet the ISO standard.