Nevyn (5/5/2015)
You seem to be trying to argue with me about what my smartphone SHOULD do.
I am telling you what it IS doing, since you told me to check.
No, I'm telling you what my smartfone does.
And you're telling what it would do if you'd programmed it.
And among other things it will let me store "+-+-+-+-+-+-+-" in my contacts, and retrieve it later. So I am pretty sure that any parsing or validation of the number is happening when it tries to dial and that it can handle characters. And while it doesn't give me the keyboard for entering with letters it will happily sync with google contacts, which happily lets me store the phone number "this is a string".
Yes, it will let you store whatever you've entered, and if it cannot parse it into a proper number it will store it as a string.
But I can assure you - if you try to call any number stored as a string you're not gonna get anywhere.
Because phones store as a single string only improperly entered numbers.
If you think that's idiocracy, please feel free to take it up with Samsung, who made the phone, or Google, who wrote the OS and the Contacts app.
I'm not gonna take on them because I believe they're doing all right.
I have not used Samsung a lot, so I'll apeak from my exoerience with iPhone and Alcatel (Android phone).
When I enter a sequence of digits into the phone number textbox I can see the phone tries to parse it straignt away.
For example (I enter only digits, no spaces):
08 - still not a number, remains a string
08 1 - ooops, 08 is a possible long distance code, separate it from the rest of the number
0811 - nah, "08" cannot be a code within such sequence, single string again
0811 4 - "0811" might be one of those "free calling" access codes (again, according to the rules of the country where I'm in), must be separated.
0811 456 7 - we use to separate 1st triplet of a number for human convenience, so it follows the common convention
0811 456 7422 - the number seems completed and valid, all good
081145674221 - ooops, adding an extra digit makes the number invalid - all the parsing is gone, the sequence to be stored as a string, because the number is obviously incorrect.
If I would be in Australia I'd see the same behaviour when entering numbers starting with 1800 - it's their free calling prefix.
But while I'm in NZ my phone takes everything started with "1800" and unrecognisable sequence and stores it as it is - with no parsing.
Smartphones are much smarter than you think they are.:cool:
Also, FWIW I can also store a comma and a semi-colon at any point in these strings. Which lets me store a phone number that pauses 3 seconds (say before entering an IVR selection or extension) or WAIT for me to press something to continue. Again, not sure what numbers you think it stores for those behind the scenes.
They show you how they save it by placing separation marks inside the sequence of symbols.
Just don't ignore the signs. 🙂
Or it means your phone dials that number anyway, but the network is smart enough to recognize that you specified the same country the network is on, and route the call accordingly.
No it does not mean that.
Our local newspaper regularly publishes letters from the readers (mainly elderly one, who use not so smart old phones) which dial numbers as they are presented in, say, Yellow Pages, including the city codes and then charged with their telco for long distance calls.
The papers raised the issue with the telcos but they responded that they cannot do much about that - as soon as they receive initial digit "0" (operator) the call i redirected to another commutator, and the following sequence of digits is processed over there.
I tried it myself - and yes, I was charged for a long distance call despite I was calling my neighbour.
I am not sure that that experience should be the basis for asserting some sort of universal best practice for storing phone numbers in any database, particularly since a great many (perhaps an overwhelming majority) of them are in no way connecting to any sort of automated dialing system.
“Nothing is good but mediocrity. The majority has settled that, and finds fault with him who escapes it at whichever end.”
? Blaise Pascal, Pensées
“Whenever you find yourself on the side of the majority, it is time to pause and reflect.”
? Mark Twain
“Wrong does not cease to be wrong because the majority share in it.”
? Leo Tolstoy, A Confession
You may find more of these here:
http://www.goodreads.com/quotes/tag/majority
I cannot be sure my practice should be taken as a universal best practice for all - the scope of testing was extremely limited.
But the practice which failed even within this limited scope should definitely never be used ever.
You never know how your data will be used, so you better keep in in order.
Even if those numbers to be presented only to humans - it's better to separate long distance codes from the actual number while saving rather than force people to parse it while reading.
Those people who separated them on paper forms might had a point, don't you think? 😉
I am also not sure how you are handling leading zeroes in your best practice, and still not sure what you are labelling your various phone number columns, since their significance changes country to country (and sometimes varies based on mobile or not). But still eminently curious if you'd like to further propose a best practice.
Leading zeroes are stored in the dialing rules pattern, not in the phone numbers.
When long distance/international codes are present and different from the dialing location the sequence builder adds them where needed.
Keep in mind - they are not always leading zeroes, they may be "1" as in Australia, or "8" as in Russia, or whatever else those politicians will invent tomorrow.
That's another reason to keep country-specific prefixes and definitions away from actual numbers.
_____________
Code for TallyGenerator