This is easy enough I figure I'll send you a pull request later today, but thought I'd write an issue anyway to start a discussion about this. When I send a ZIP code with a +4, e.g. "60622-1234", Area raises an ArgumentError: "You must provide a valid area or zip code". For my purposes I don't really care about the +4, so I could filter it out before asking Area, but Area really should handle these kinds of ZIP codes as they are considered to be well-formatted and are accepted by the US Postal Service as valid zip codes.
I think it would be unreasonable to ask it to know exactly where each +4 zip code is, geographically (like, lat/lng should come from the first five digits because seriously nobody should care about the last four), but including the +4 is definitely not good enough cause for throwing an exception.
This is easy enough I figure I'll send you a pull request later today, but thought I'd write an issue anyway to start a discussion about this. When I send a ZIP code with a +4, e.g. "60622-1234", Area raises an ArgumentError: "You must provide a valid area or zip code". For my purposes I don't really care about the +4, so I could filter it out before asking Area, but Area really should handle these kinds of ZIP codes as they are considered to be well-formatted and are accepted by the US Postal Service as valid zip codes.
I think it would be unreasonable to ask it to know exactly where each +4 zip code is, geographically (like, lat/lng should come from the first five digits because seriously nobody should care about the last four), but including the +4 is definitely not good enough cause for throwing an exception.