Postal code validation incomplete

[karptonite]

The postal code patterns for subdivisions only looks for a partial match, however, if there is a subdivision postal code pattern, the country postal code pattern is not checked.

This means that any string that contains a subset of the subdivision postal code pattern tests as valid, even if the string is the wrong format otherwise.

Unfortunately, it appears that some countries (China/Taiwan) do not have a consistent country-wide postal code format, so just applying the country format in addition to the subdivision format test will not fix the issue. I'm not sure what the right solution is, but it would be good if the format of a postal code were tested in addition to the subdivision string where a consistent format is available.

[karptonite]

On further investigation, it looks like the data at http://i18napis.appspot.com/address does include what we'd need to validate the full postal code formats, in the sub_xzips field for the country. That doesn't mean it would be trivial to implement, but the data seems to be there.

As an aside, it might also be useful to import the zipex fields into the address format as a postal_code_example.

[bojanz]

1. Running both the country-level and the subdivision-level checks makes perfect sense.
2. I don't quite understand what the sub_xzips field gives you? It's not documented in the java library, and it appears to have only a few entries for China? I see that the generic validation for China is "6 numeric digits" and most subdivisions have no rules of their own.
3. I didn't import the zipex field because I didn't see where I'd use it. The only possible use case is showing it inside the postal code validation message, but that would require us to import both the country and subdivision level examples, figure out which one to show. If a subdivision has a validation rule but no example, the country level example might not actually apply.

[karptonite]

1. I have a local branch where I run both the county level and subdivision level check. The problem is that China (at least) has a country level postal code that does not apply to all subdivisions in china. In particular, it does not apply to Taiwan, which has a three (optionally 5) digit postal code. So if we ran the country level, all mail to Taiwan would fail to validate. This is why I didn't make a pull request for it.

2. the sub_xzip field would fix the taiwan problem, if we could use that data appropriately. It shows the subdivisions which have postal code patterns which are not consistent with the country, it seems.

3. I would use the zipex field to show an example zip code when there is a zip code format violation, rather than just saying this zip code is invalid. I might also use it to show an example in th form before the user fills out the postal code. I agree that there would be complexities regarding which one to show.

(edit) To be clear, by Taiwan, I mean the Subdomain of China, id CN-71. Taiwan can also be selected as a country, in which case the postal code will validate properly. But if someone selects country China, subdomain Taiwan, validation would fail if we ran the China country level validation against it.

[bojanz]

Okay, I understand now. I have a commit ready, running the generate.php script to get the additional info.

Pushed the first fix via 75efe70, it fixes the Canadian test fails.

[karptonite]

Yes, I had the same test failure. I assumed that it was the test that is wrong, however. According to this:
https://www.canadapost.ca/tools/pg/manual/PGaddress-e.asp
Postal codes in Canada really have to be in upper case.

[bojanz]

Canada specifies the postal code as one of the "uppercase fields", so the field will be uppercased by the PostalLabelFormatter, satisfying those requirements. However, the Java library's approach on being less strict on input makes sense, since the case is something that is easy to enforce down the line, and usually not worth throwing an error for.

[bojanz]

Opened a PR, please review :)

[bojanz]

Okay, so we fixed the main part of this issue.

I'm open to a PR that adds postal code examples and uses them in validation messages.