This is why I do not bother attempting to interpret the core number once I have dealt with IDD codes, country codes, extensions, and various representations of multiple numbers. Figuring out an area code is beyond the scope of this set of tools -- it does, however, make a huge step in providing a base phone number suitable for interpretation by a module tailored to a particular country or region.

I admit that my *display* functionality is US-centric. It chunks the core number width 4 digits on the suffix, preceded by groups of three (or less if the first digits). So in your example, dd dd dd dd would come out looking like d ddd dddd.

That's just cosmetic, however. The internal representation makes no distinction for area codes of any sort. The PhoneNumber.pm module can be provided with new chunked_number() and as_string() methods suitable for any locale. If I ever put it on CPAN I would attempt to structure it so that subclasses could easily provide for internationalization (perhaps based on country code, but with a default format for the local region).

(it's worth repeating that the actual display of these numbers was more of an afterthought -- the main thrust is the normalization and parsing of unverified and unruly international phone number strings)

Matt