fix(location): Pad en_US ZIP codes left to 5 characters if needed

[matthewmayer]

fix #2277

Added a test and a fix. Not sure if this is the best long-term solution, but since only en_US uses this method currently, it seems a fairly low-impact solution.

Also fixed Puerto Rico range so its not always 00000

[codecov]

Codecov Report

Merging #2278 (fbf3ca5) into next (7f0daf3) will decrease coverage by 0.01%.
The diff coverage is 94.91%.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #2278      +/-   ##
==========================================
- Coverage   99.60%   99.59%   -0.01%     
==========================================
  Files        2644     2644              
  Lines      245770   245617     -153     
  Branches     1085     1079       -6     
==========================================
- Hits       244798   244630     -168     
- Misses        945      960      +15     
  Partials       27       27              

Files Changed	Coverage Δ
src/definitions/location.ts	0.00% <0.00%> (ø)
src/locales/en_US/location/postcode_by_state.ts	100.00% <100.00%> (ø)
src/modules/location/index.ts	99.17% <100.00%> (+0.16%)	⬆️

... and 1 file with indirect coverage changes

[ST-DDT]

Team decision

This looks like a temporary workaround that is tailored for en-us only, but doesn't consider other zip code formats such as Poland's:
https://en.wikipedia.org/wiki/Postal_codes_in_Poland#Postal_codes_used_for_more_than_one_settlement
Maybe we should consider adding support for fake patterns instead.

[ahaberbosch]

It would be nice if ranges in addition to patterns could be specified. Realistically, most states don't seem to utilize the full range.
For example, AZ has a gap between 85087 and 85117, and several other gaps.

[ahaberbosch]

Team decision

This looks like a temporary workaround that is tailored for en-us only, but doesn't consider other zip code formats such as Poland's: https://en.wikipedia.org/wiki/Postal_codes_in_Poland#Postal_codes_used_for_more_than_one_settlement Maybe we should consider adding support for fake patterns instead.

There's already support for patterns, but it seems to be exclusive to the usage of zip code by state. Could they be merged?

[matthewmayer]

Team decision

This looks like a temporary workaround that is tailored for en-us only, but doesn't consider other zip code formats such as Poland's: https://en.wikipedia.org/wiki/Postal_codes_in_Poland#Postal_codes_used_for_more_than_one_settlement Maybe we should consider adding support for fake patterns instead.

in many countries, postcodes/ZIP codes don't match up with state boundaries.

For example note in that Wikipedia article "Postal districts and their subdivisions are not related to the administrative division of Poland."

So I doubt there will be much usage of this outside of en_US.

[ahaberbosch]

Team decision
This looks like a temporary workaround that is tailored for en-us only, but doesn't consider other zip code formats such as Poland's: https://en.wikipedia.org/wiki/Postal_codes_in_Poland#Postal_codes_used_for_more_than_one_settlement Maybe we should consider adding support for fake patterns instead.

in many countries, postcodes/ZIP codes don't match up with state boundaries.

For example note in that Wikipedia article "Postal districts and their subdivisions are not related to the administrative division of Poland."

So I doubt there will be much usage of this outside of en_US.

Actually, it looks like the proposed PR could be useful for Mexico, specifically the mexico City boroughs. The Mexican zip codes are modelled after US zip codes, with some mexico city zip codes prefixed with zeroes.

[RobinvanderVliet]

So I doubt there will be much usage of this outside of en_US.

I tried implementing it for the Netherlands and our provinces, but I ran into a problem as our postal codes also contain letters. Dutch postal codes are in the format /[1-9][0-9]{3} [A-Z]{2}/.

I found the numeric ranges for the provinces, and for the letters we could just use 2 random letters.

[matthewmayer]

My feeling is while we should support this for legacy reasons for en_US we shouldn't put too much effort into trying to make this work in every locale- if this feature didn't currently exist I suspect it would be rejected as a feature request, since we generally avoid features that allow you to create consistent data between methods (eg city that matches the state).

[matthewmayer]

I saw from the meeting notes you want to try to achieve this using patterns instead so it would work for more countries, but not sure how the current behavior could be replicated using string patterns as it includes numeric ranges.

[ST-DDT]

I saw from the meeting notes you want to try to achieve this using patterns instead so it would work for more countries, but not sure how the current behavior could be replicated using string patterns as it includes numeric ranges.

0{{number.int(range)}}

[matthewmayer]

have changed this to use string patterns passed to faker.helpers.fake

[Shinigami92]

have changed this to use string patterns passed to faker.helpers.fake

Oh 😲 that is very interesting
We should discuss this in next meeting, but looks promising to me 👌

[ST-DDT]

There seems to be a merge conflict.