Too strict: Unable to parse '000000' date

[silentbugs]

Hello!

Some of the GS1 barcodes I am scanning contain some silly dates, such as '000000'. Currently parsing fails completely, as month 0 and day 0 are not a valid month/day respectively.

Is it possible to decide how certain errors are handled, and if they should fallback to defaults or fail completely?

Example of a GS1 barcode that fails: 019906600092731431030078881500000010215359

[jodal]

Currently, Biip has no configuration options for making the parsing more lenient. It follows the GS1 specifications quite strictly.

However, being able to control Biip's strictness has surfaced as a request several times now, so I think this is the highest prioritized item for any further development of Biip.

[silentbugs]

Thanks for the swift reply. I really like libraries that are strict with specs, so thanks for doing this.

I will probably end up using biip because it seems like a great library and since I'll have to find a way to parse such barcodes I'll probably fork it and write a PR for this.

I was thinking of writing a class with most of the things currently defined in biip (such as _parse_date()), so that users import that class and configuring it, should they need to. Importing parse directly will give you the parse method with the defaults, as it currently works.

Any thoughts?

[jodal]

PR #385 moved all configuration flags to a configuration object. This means that we can now easily add more configuration options without having to pass the new flags through several layers of indirection.

PR #386 added a new configuration option gs1_message_verify_date that can be used to make Biip ignore GS1 messages with dates that are invalid. This will be part of the upcoming v4.0 release.

Feel free to open more issues if you have other cases where Biip needs to be less strict.

[jodal]

This has been released in Biip 4.0.0.