SyntaxException for DateTimeParser::parse not working

[aleks-f]

From http://stackoverflow.com/questions/25285740/syntex-exception-for-datetimeparserparse-of-poco-not-working :

In the documentation to Poco::DateTimeParser:.parse(const
std::string& fmt, const std::string& str, int& timeZoneDifferential)

Parses a date and time in the given format from the given string.
Throws a SyntaxException if the string cannot be successfully parsed.

As I understand this sentence the given datestring "str" must be in
the format described in paramter "fmt", otherwise a SyntaxException is thrown - or do I miss something ?

But even if i give wrong format like "sjdcg-12987-kjchsjkc" or an empty format. its parsing the string and giving some garbage value.

How can i solve this issue:

the code is like this-

string datetime="jnghjgnbcfjb";

try
{
  DateTimeParser::parse(DateTimeFormat::ISO8601_FRAC_FORMAT,datetime,dt,tzd);
}
catch(const Poco::Exception& exc)
{
  cout << exc.displayText() << endl;
}

[obiltschnig]

Will update documentation to reflect current behavior.

[aleks-f]

@obiltschnig note that some changes in this fix will potentially break some users code - we have been accepting letter timezones other than USA for RFC822 format, which is not allowed by standard (maybe open another bug for this, just so we don't lose record of it?)

zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 /  1ALPHA                       ; Military: Z = UT;
                                                 ;  A:-1; (J not used)
                                                 ;  M:-12; N:+1; Y:+12
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                 ;  hours+min. (HHMM)

[matejk]

Is there any chance that the changes to improve reliability to parse date/time get merged to stable release branches?

[aleks-f]

@matejk would you be willing to merge this for 1.13 (due December 11)? It's a core functionality and we may break things a mentioned above, so lets test it well and we will make a release note about breaking changes.

The fix is here

[matejk]

Of course I'd be willing.

[matejk]

Parser code is cherry picked from develop-experimental and corrected. Code is available on branch 569-DateTimeParser-cherry-pick.

Few observations:

• regex contains all of the available timezone codes. That list must be kept in sync with the table in the parser.
  • Would it make sense that timezone strings are validated when interpreting them?
• RFC 822 and RFC 112 timezone differential hours are not recognised (parsing fails)
• Specifications for RFC 822 and RFC 1123 use less timezone strings as defined in Poco
  • Shall that be corrected in the parser?

https://datatracker.ietf.org/doc/html/rfc822#section-5

@aleks-f

[killerbot242]

I wonder if the solution is fully ok, in our code base it seems to break things. One could also argue the old code was doing an improper job.
For example : the following used to be accepted (note a space in front and at the end, both accepted and nicely ignored) with Poco 12.x and earlier.

const std::string input{" 2024-01-06 11:05:24 "}; int ignoreTz{}; const auto dateTime = Poco::DateTimeParser::parse("%Y-%m-%d %H:%M:%S", input, ignoreTz);

Poco 13.x raises the exception. Code breakage code be less impacting if the implementation would continue to remove the whitespace, well most probably it does, it is the addition of the regexes that don't like the whitespace.

[aleks-f]

The old code was indeed accepting garbage silently. I'm thinking trimming spaces may be an acceptable preprocessing step. @matejk what do you think?

[matejk]

Taking a look at the pattern and the input it somehow seems to be correct that the input is rejected, because it does not match the pattern.

Yes, it would be possible to use Poco::trim or Poco::trimInPlace in preprocessing step inside the parse, however it is really easy to use one of those before calling the parse function if it is expected that the input might contain some excess whitespace.

My recommendation is to do cleaning of the input before calling parse.

[killerbot242]

I agree that trimming being done by the user code, makes much sense, and would be the way to go when this was a new feature.
I am not so sure, for an existing feature, things will break, and unfortunately not a compile time, but a run-time.
This might be an expensive side effect, maybe justifying for the sake of backwards compatibility to trim on the inside ?

[matejk]

We marked this change as breaking only in the release notes and not here, unfortunately.

And you are right, a compromise between the previous implementation and the strict one could be implemented to avoid some unexpected run-time side effects.

@aleks-f, what if we introduce a parameter strict to parse that defaults to false and do cleaning of the input only in that case? In 1.14 we could perhaps make that variant of the parse deprecated.