Shane,
Thanks for your review of has' Date.scptd script library.
I was just going to ask if anyone had used it, or had comments on it. 😄
I'm not sure if I'm the OP here or not, but my (roughly) ISO date string processing is to handle these cases, ALL of which assume a local time zone. Note that the date and time may have ANY 1-char delimiter, such as SPACE
or "T".
• pDateStr | text | Date String in ISO format
Assumes local time zone
If time is included, assumed to be 24-HR format
pDateStr MUST be in the format of
YYYY<delim>MM<delim>DD
OR, if time with minutes is included:
YYYY<delim>MM<delim>DD<AnyChar>HH<delim>MM
OR, if time with seconds is included:
YYYY<delim>MM<delim>DD<AnyChar>HH<delim>MM<delim>SS
in local time.
where <delim> can be any character
like any of these:
2016-01-05
2016-01-05 13:01:15
2016-01-05T13:01:15
2016-01-05 13:01
2016-01-05 13:01:15
I still need to add validation to trap for any time zone info at the end of the string. I will probably just throw an error to keep things simple. Thanks to Shane for pointing out the need for this.
Jim Underwood
aka JMichaelTX
Not that Apple's code doesn't include its own embarrassing share of bugs, flaws, and limitations
It does...
but given the choice between relying on their ISO8601 parsing code and your (or my) ISO8601 parsing code, it's not even a contest.
Except that what the OP wants parsed is not "canonical" ISO 8601 as defined in your library -- his sample string, and the ones in the comments to his script, don't match the strict rule you use.