correctly pointed out that changing the behavior of %Y would cause years < 1000 to not be parsed correctly, which forced me to do some more digging.  It turns out that the fix applied for  was the cause of the behavior change cited in this issue.  The fix for both this issue and the prior one involves solving the prior issue with a different method.

I found the problem exhibited by the example code: readValue() within stringlib claims success when it reads any number of digits less than the maximum. For the case where the input is a two-digit year but the format string wants a four digit year, readValue() will "successfully" parse the two digit year and then an invalid time structure is eventually created. This code was last touched in 2011, so I'm somewhat mystified as to how it worked in a version 6.x.x platform.

As to the problem where reversing the list of possible formats to try, there is not an easy way to avoid that problem. The best solution here probably lies in documentation: Recommend to the caller that any formats containing %Y should appear before formats containing %y, as %y results can encompass %Y results.

Please assign to me.

Any ideas?