Why should I use PARSE_PHONE vs FORMAT_PHONE?

Looking at the docs for PARSE_PHONE and FORMAT_PHONE, it looks like they can both achieve the same mission. Why should I use one vs the other?

2 Likes

This is an interesting question!

PARSE_PHONE and FORMAT_PHONE are subtly different. Crucially, PARSE_PHONE always returns input that counts as a Phone Data Type, whereas FORMAT_PHONE does not.

You can think of PARSE_PHONE as a function that makes phone number easily-readable for computers, while FORMAT_PHONE is a function that make phone numbers easily-readable for people.

A common use case for PARSE_PHONE is to take a phone number entered by an app user (which might use local formatting conventions and lack details like the country code) and ensure that it gets saved in a format that can be used to automatically send texts and phone calls (which requires a standardized format that encompasses details like the country code).

A common use case for FORMAT_PHONE is to take a phone number collected from an incoming call (and automatically saved in E.164 format) and return a string that formats the phone number according to local standards. Using local formatting conventions makes it easier for humans to read, even though the lack of standardization makes it a pain for computers to parse.

The format of the output of FORMAT_PHONE can vary, because it can return phone number formatted according to different specifications – including E.164. In practice, this means that there is some overlap in what PARSE_PHONE and FORMAT_PHONE can do, but they’re ultimately optimized for different use cases.

5 Likes