Falsehoods programmers believe about time:
More falsehoods programmers believe about time:
Falsehoods programmers believe about geography:
Falsehoods programmers believe about addresses:
The border is where the river used to be... total chaos now
> 15. Unix time is the number of seconds since Jan 1st 1970.
The section you quote from Wikipedia shows why this one is false: leap seconds. Similar to how the number of hours between 00:00 and 3:00 in most of the United States depends on whether the timezone remains constant, springs forward, or falls back, the number of seconds between two Unix timestamps depends on how many leap seconds were inserted or deleted in that time frame.
> 16. The day before Saturday is always Friday.
This one is true only within the assumption but I'm not sure if the falsehood is literally false. When Alaska did the calendar change it had two consecutive Fridays (October 6th & 18th, 1867). This gives us the day after Friday not being Saturday but technically not the day before Saturday not being Friday. The falsehood still holds in spirit (outside of the assumption), of course, and it's possible somewhere else had it be true in practice as well.
> 27. The weekend consists of Saturday and Sunday.
The weekend differs across the world. Friday and Saturday is another popular one but Brunei gets a special shout out for having a Friday and Sunday "weekend" with Saturday being a working day.
> 59. DST is always an advancement by 1 hour
As far as I know, this is currently true if you aren't dealing with historical datetimes but Singapore will mess you up with historical data. They had a really odd case where they went on DST by advancing 20 minutes and then ended DST without changing the clock at all.
So, not only does the street have a number, it has TWO. And your address ends up being:
"17 of November 1894 230 3C" (we put building numbers after street names).
If you must do validation yourself, put in the time to research it and get it right, don't just bang something out based on your own experience of the problem domain.
Edit: one more: if you must validate, keep this separate from how you store the data, so you can more easily fix your mistakes or adapt to changes.
This is like trying to accept all valid email addresses according to the RFC. Even when we have a spec, there's a maddeningly complex array of possibilities, but it's ok if for almost everything we accept some subset of it. It would be madness, for example, if we forced government employees of a particular country to be able to deal with all possible scripts of the world, including Prince's symbol, just to account for all possible ways that humans name themselves.
Sometimes these accents are disambiguating...
Many could handle the characters, but where I sent a paper form the person entering the data didn't know how to type it.
This must be a problem for somewhere like Armenia, where I have seen people really struggling with the English alphabet. Education was Armenian and Russian for a long time.
(There are postcodes in Denmark, but Ø is the first letter of East, so is a very broad code, in a way.)
That documents that not all addresses have postal codes. This is another example of the real world existing in order to give programmers kicks in the head.
I don't think any of them about programmer hubris specifically. A lot of people could fail to realize that "23:59:60" is a valid time, for instance.
By the way, for people reading this, from my own experience, at least 30/40% of French people will put the last name first in the form, whatever the text says, so to get better data, the best thing is to put them in the order (last name / first name) for them to reduce the number of errors.
Me: Try this test.
Dev: Oh, didn't think about that one, let's add that case.
Me: How about this?
Dev: What? OK OK, let's support that too.
Me: And this one...?
Dev: Wait, what? How is that even...?
The code is about 200 lines now, and we've blown the afternoon, and it still doesn't properly handle Xxxx, so I'll forward him the "Falsehoods Programmers Believe About Xxxx" article.
Dev: Oh crap, maybe I should have looked for a tried and true library that handles Xxxx....
Me: Yes, grasshopper...
In general, in Europe "0" is national dialing prefix, leading to numbers written in the format of:
+44(0)870123456, meaning dial 0870123456 from within the UK, and +44870123456 internationally to reach the same number (i.e. "0" goes away in international format).
However in Italy, leading "0" in the national dialing format is an integral part of the phone number itself (only for non-mobile numbers); for example:
(+39)051234567 meaning 051234567 when dialing from within IT, and +39051234567 internationally (i.e. "0" stays in international format).
EDIT: Mobile numbers in Italy don't have leading "0", and could only be dialed in full/international format either within the country, or internationally.
In parts of Europe. Denmark has no area codes at all.
Ideally I'd prefer them to allow me to leave the number blank, of course.
But seriously, this is more about the limitation of POTS, Plain Old Telephone Systems.
Often you don't notice the poor quality while using POTS. But if you ever listen to an NPR show where a journalist is calling into the studio over POTS, it's quite jarring how bad it is.
With all the code they wrote to generate that pop-up, you'd think they could massage my input into the format they wanted in the first place...
Or web forms will reject a phone number if it has non-numeric characters like "-", which many people would probably think of as an integral part of their number.
There any many countries without postal codes at all, and we have to enter fake numbers to validate forms.
Post codes aren't quite the same thing as Zone Improvement Plan codes. ZIP codes are just the peculiar implementation in the US of the general post code concept.
An important difference between ZIP codes and Canadian post codes is that, since there are many more possible post codes than ZIP codes, post codes tend to cover much smaller regions than ZIP codes. In many cases, only a handful of individuals up to a single individual may have a Canadian post code. Thus, publishing Canadian users' post codes can severely harm Canadians' privacy, as you may as well be publishing their exact address.
14. In Israel, certain advertising numbers start with a *.
But along with another user's comment that in Italy, leading zeroes are required, it's clear that (at least in any international application) phone numbers need to be strings.
I saw a database once that stored phone numbers as ints. elsewhere in the software, they tried to take the mean of the wrong column. If the phone numbers had been stored as strings the error would have been obvious. As it was, the error survived in production for a disturbingly long time. The users persisted in thinking the output was meaningful even after the problem was discovered.
I'd honestly have rather it stored a NULL than that result though.
Don't ever do this.
Although, the other reason that won't work (which I thought you were going to say) is that it'll end up as -X1XX!
In St. Louis had 314 and 636 area codes, sonetimes they needed a 1 in front of them based on where you called from. 636 was west county like St. Charles 314 was St. Louis city and North, East, and West county. They used a different area code to make more numbers due to demand.
Edit: Here is a list of emergency numbers. 77 and *999 are on the list for different states. http://www.ou.edu/police/dpsinfo/state-by-state-cellphone-hi...
As someone who travels a lot I can attest to the annoyance of messaging apps which identify users by phone number. WhatsApp is a good example.
Another terrible design is one time passcodes which are sent over SMS. When a number gets recycled it can become impossible to recover access to a service which you forgot was associated with the number you had at the time of signing up in another country.
Since I often change cell phone numbers because I move frequently (nationwide free long-distance has never caught on in Canada), I like having one number I can re-direct as needed. When I go overseas and buy a local SIM card, I'll re-direct it to that so I can keep in touch.
Telecoms have said they can't take it. The government tax agency can't accept it. Banks won't accept it.
Now when I call in and they ask what my phone number is to verify my identity, I have to rhyme off a string of old phone numbers.
020 1234 5678 London.
0121 123 4566 Birmingham.
01234 567 890 Some small town somewhere.
07987 654321 Mobile. (Is that right? Maybe a second space.)
The first two are actually valid numbers (some of my old numbers, which are still active, but unused).
Btw, an area code doesn't have to actually refer to that area — you can keep phone numbers if moving across area code boundaries in Germany, so a 040 number might actually be used by someone living in 0431.
Alternatively, new area codes can be overlaid on top of existing ones - in NYC, Manhattan has 212, 646 and 917. A phone number that's invalid one day can become valid the next day if a new area code is introduced.
Many years later, a friend borrowed my cellphone in an area where phone numbers were often dialed as seven digit. Not thinking about my being from out of state, he only dialed seven digits, and happened to get some rather confused person back in Portland. I had no idea my cellular carrier would even allow you to do that!
So overlay area codes can combine with number portability to have some odd results. A number may or may not be considered valid by the carrier, and may or may not get you who you expected, and in edge cases this may depend on the carrier.
Does anyone know of any other easily verifiable resource which is on average available to very nearly one per person?
I challenge you to produce any country (link supporting what you say) where phone numbers with SMS DELIVERABILITY are not scarce eg dont need a device or endpoint to be registered with some carrier or can be obtained by the hundreds.
I could dial 0431 4242 1234, or 0431 4242 1235, and they'd refer to the same account.
In fact, many business lines allow you infinite suffixes.
0431 4242 123456789 is a possibility.
All with SMS deliverability (SMS delivered to non-SMS numbers are transmitted via text-to-speech).
In South Africa, we have a lot of SMS services that tack five or so digits onto the ends of normal numbers as unique identifiers, so what I assume was a programmer's false belief about phone numbers did some real harm there.
This method broke in 1995.
Monaco? WTF? And Slovenia doesn't make much sense either. Why wouldn't it be Serbia and Albania?
It appears to be because one of their mobile phone service provider's network is managed by Monaco Telecom.
Any Brazilians here who can confirm whether this is true?
I know that in Brazil you can select a preferred carrier for a long-distance phone call by dialing a prefix. For example, you'd dial 014 ahead of your phone number to choose Brasil Telecom or 021 to choose Claro. But this is optional as far as I know. If you don't dial any prefix, you get a default carrier.
If I need to validate a phone number is correct I'll send an SMS and ask the user to enter a code, otherwise I'll assume they know their phone number better than me.
This one got me when I ran a Japanese website. Unicode (deriving from Japanese standards) has "fullwidth forms" for Roman letters and numbers. Thus your users can enter a phone number as 0123456789 or ０１２３４５６７８９ (or even a mixture), and your code had better be able to cope with it.
If you're dealing with short codes or other highly regional things... Good luck...
Not sure this suggestion is a truly pragmatic approach, because there is often very little else to determine SMS reachability up front, which is a common want. One might assume mobile until an adequately reliable SMS provider determines that the number is in fact not a mobile reachable SMSC-managed number. Fun fact: in China, there used to be multiple mobile messaging systems including a non-SMS system with weird gateway restrictions and no UCS-2 Unicode support. Another fun fact: UCS-2 kills bytes rapidly, you are better off (ie. get more length per message) using legacy local encodings like TIS in Thailand, etc. from a cost/length perspective. If you want to achieve that today, almost no mobile messaging provider can help you, you need to build custom SMS PDUs through their binary PDU submission interface, which is documented but still something of a black art and typically has very different reachability constraints to standard messaging (whole operators may suddenly become inaccessible).
2. A phone number uniquely identifies an individual [...] It wasn't even that long ago that mobile phones didn't exist, and it was common for an entire household to share one fixed-line telephone number. In some parts of the world, this is still true, and relatives (or even friends) share a single phone number.
This may be true, but on a related note, it is the trend now in many countries to require formal government identity document submission in order to obtain a SIM or make it functional through user registration. Therefore, in some parts of the world, you can skip a whole lot of mucking around with mobile-connected services by re-evaluating the probable bad-actor risk metric for customers from those countries through considering probably relatively strong police identification efficacy of abusive accounts in these markets.
3. An individual has only one phone number. [...] Obviously, this isn't necessarily true.
An individual has zero or more numbers which are not necessarily unique to that user, long term accessible, or of any certain or constant type or origin. Someone else may take these over at any time, so they cannot be relied upon solely as a trusted channel to the user.
5. Each country calling code corresponds to exactly one country [...] The USA, Canada, and several Caribbean islands share the country calling code +1. Russia and Kazakhstan share +7.
This is only half true. They generally have longer prefixes. For example https://en.wikipedia.org/wiki/Khazakstan shows +7-6xx, +7-7xx and much of the +1's can probably be reliably split through prefixes.
6. Each country has only one country calling code
Further example: calling Taiwan via China.
Another point: some endpoints need PABX suffixes to reach, for example voicemail or via corporate systems. There is no real standard for these programs, which tend to incorporate functions like "wait for initial connection", wait x seconds", "wait for a sound", or "wait for a second dialtone". In some countries people will write 123456 x7 for extension 7, but often multi-level inputs may be required (classic case: almost any telephone-based customer support system), in which case there is no standard.
Finally, I was inspired by this document to write a similar one about International Bank Account Numbers (IBAN), see https://news.ycombinator.com/item?id=11321785
German doesn't really have long phone numbers. Those are just phone number phrases made of individual small phone numbers, but strung together by the German writing system.
The focus on programmers is because virtually every point is about handling phone numbers as data to be processed and worked with, which is a fairly unique perspective that, as far as I can think, only programmers have. Most of the points are pitfalls that might trip up a programmer when working with code that takes a phone number as an input and needs to validate it.
While I'll grant that your alternative titles are much less aggressive, the original title really isn't condescending unless you read into it as such, in my opinion. It doesn't say "all programmers", just programmers, and all points seem like fairly common misperceptions.
Links in other comments.