Is it better to store telephone numbers in some canonical format or “as entered”?

Question

Storing a telehone number in some kind of canonical format has several advantages from a programmers point of view, but it might confuse the user, if sudde

Answer 1

The UK is a special case as we have variable length STD (area) codes and variable length subscriber number itself. The longer the STD code the shorter the number. Germany and a few other countries also have a similar system.

Numbers are mostly 10 digits after the 0 trunk (long distance) prefix, but several dozen areas also have some 9 digit numbers.

• 020 2345 5678 (London) also Cardiff, Southampton, Portsmouth, Coventry and Northern Ireland
• 0115 234 4567 (Nottingham) also Sheffield, Bristol, Leicester, Reading and Leeds
• 0141 345 5678 (Glasgow) also Birmingham, Edinburgh, Tyneside, Manchester and Liverpool
• 01332 234 456 (Derby) most other areas (about 580 areas) also use this format
• 01750 45678 (Selkirk) and about 40 areas have some numbers that are a digit shorter
• 017687 45678 (Keswick) also Langholm, Hornby, Hawkshead, Grange-over-Sands, Sedbergh, Wigton, Raughton Head, Brampton, Appleby, Pooley Bridge and Gosforth.
• 016977 2345 (Brampton) The only place using "5+4" format.
• 07812 123 456 (mobile numbers)

Beware that 0800 numbers can be different lengths, e.g. 0800 567 1234 or 0800 234 456. The old 0500 numbers are also a digit shorter, e.g. 0500 456 456.

Additionally some people like to group their numbers 234 234 while others use 23 23 23 (depending on the actual digits).

There are arguments for storing as entered and storing in a single form:

If you store the number as just the sequence of numbers then you can output it in any way you want, either by taking into account user preferences or their locale and splitting the number up according to "rules" (what ever they may be).

If you store as entered then you'll always display it as the user expects, but you'll need to strip out non numeric values before using it, which if it's often could be expensive.

Answer 2

Let the user enter whatever format they are comfortable with, then validate it and store it in the database in a consistent format - preferably with the country code included.

When displaying the number, display it in the correct format for that number range, with correct spacing, and for national format numbers add parentheses around the area code if needed.

If displaying as an international number, be especially careful not to include any international access code as that varies from country to country, e.g. showing a French number as 011 33 55 66 77 88 (as dialled from the US and Canada) is of no use to UK readers because they will dial 00 33 55 66 77 88; always use the +33 55 66 77 88 format.

Also with the international format, never include the (0) trunk prefix. The international format should only include the digits that are dialled from abroad.

Answer 3

Useful resources:

List of UK area codes: http://www.telephonenumbers.co.uk/Telephone-Area-Codes-UK/i=2 (dated July 2011).

List of number lengths/number formats for the UK (covers 01 and 02 numbers): http://www.aa-asterisk.org.uk/index.php/01_numbers

Allocations in "Mixed" areas: http://www.aa-asterisk.org.uk/index.php/Mixed_areas

Allocations in "ELNS" areas: http://www.aa-asterisk.org.uk/index.php/ELNS_areas

UK prefix list with formatting information: http://www.aa-asterisk.org.uk/index.php/Sabc.txt

Formatting UK numbers is certainly a LOT more complex than (01234) 567890, (0141) 234 5678 and (020) 3456 7890.

Answer 4

Store it however you prefer, but turn it into human readable format before you show it to the user. And please don't force your users to enter phone numbers in a format of your choosing, let them just type it in however they like.

That's how I do it.

Answer 5

What's your userbase?

If they're going to be limited geographically (i.e., US-only) and you're going to validate numbers strictly, then format the number canonically for them -- i.e., strip out any formatting they used (like periods between numbers...) and put in the dashes (do not fail validation if they don't stick to your formatting... that's just mean). I'd store that cleaned-up version in the DB as well, not a stripped number; it makes your life a bit easier when generating custom reports, etc..

If you might have users/numbers from all over the world, it might be better to save the formatting they used. Also don't forget the case that sometimes US residents are currently traveling and using a foreign number: don't block them unintentionally.

Either way: make sure you DON'T define the column as numeric, or make it too small. International numbers with formatting can easily be over 16 chars long.

Answer 6

Separation of Duties - Content and Rendering

Store the number in a canonical format and the display format mask.

Gains:

• Canonical format for consistency, quality, and ease of analysis
• Format retained from end-user perspective
• Format re-usable to display other phone numbers in end-user preferred method
• Other format masks can be used to display canonical number to other users with a need to see the phone number

Pains:

• Parsing the phone number to the canonical format
• Parsing out the display format mask (not too painful in combination with above bullet)
• Storing the display format as an end-user preference