Hacker News Reader

Maybe not a regular customer, but there's other reasons you might have a phone field:

> In Israel, certain advertising numbers start with a *.

> In New Zealand, non-urgent traffic incidents can be reported by calling *555 from a mobile phone.

> I’ve found that anything other than integers is a mistake.

They're not integers, they're strings. Strings of digits it's true, but still strings.

Actually, a better example is 911. It is a phone number, you can dial it, but has no E164 representation.

Wouldn't it be (assuming US) +1911?

+1-911 isn't a valid E164. 911 and similar numbers can't be represented in global form, they are only represented in local form.

I discovered that the tel: URL supports local numbers with context. So the bigint scheme can't represent valid tel: URLs.

I still feel like my point is being lost.

A generic contact identifier that you’re only going to show to other humans can of course be a string. People can put whatever they want in there. But it won’t be useful for automation or other kinds of processing.

If you’re going to actually use the number in any kind of automation, including tel: urls, it’s better as an integer because then you’re forced to process the incoming number properly before you put it in the database.

In terms of E164, You’re not ever going to store numbers like 911 in a database of phone numbers that you’ll plug into automations.

The whole point of E164 is to normalise the international numbering system. Why would you not use the international telecommunications standard for numbering, to store telephone numbers that are intended to be used to contact people?

It’s the same as storing an IP address as a string. Sure, you can do it, but why? The only possible outcome is that you will eventually store useless strings that aren’t actually valid.

Of course the tel: url scheme can support E164 numbers. I mean unless your app is limited to only a single geography, why would you even want it to be local only?

> What customer has *555 as their phone number?

"Surely we won't ever need it"

“Surely accepting randomly formatted text instead of an international standard won’t ever cause problems”

how about accepting anything that can be typed with a phone keyboard `[0-9()+*;]` or whatever the right chars are? going from phone keyboard to database and back to phone keyboard should not modify what gets dialed

DTMF signalling restricts what you can dial over a traditional PSTN line. In practice you can only dial what a regular landline phone can dial. * and # are used to signal commands rather than calling numbers. There are another 4 DTMF signals, but CPEs don't generally use them.

So that leaves you with just the 10 digits. Which can be easily stored in an integer, which can then be formatted reliably for humans according to the international numbering plan.

Like IP addresses, phone numbers are just numbers. You can fuck about all you like by adding funny letters and brackets and complicated parsers (just like you can add dots and colons to an IP address), OR you can just store them as normalised E164 numbers, which will work everywhere and for which there are clear formatting rules. Just like you can store an IP address as an IP address datatype in most databases.

Almost nobody wants to store the NZ time service or 911 or anything else in a large database. Nobody is dialling an extension number over the PSTN network - that's like trying to include the port number in an IP address and calling it ... an IP address. Such numbers should be stored somewhere else.

Lots of extensions are written like that.

An internal extension on your PBX