Assumptions most programmers make about names

[TehBorken]

As a public service, I'm going to list assumptions most programmers make about names.  All of these assumptions are wrong.  Try to make less of them next time you write code which touches names.

   People have exactly one canonical full name.
People have exactly one full name which they go by.
People have, at this point in time, exactly one canonical full name.
People have, at this point in time, one full name which they go by.
People have exactly N names, for any value of N.
People's names fit within a certain defined amount of space.
People's names do not change.
People's names change, but only at a certain enumerated set of events.
People's names are written in ASCII.
People's names are written in any single character set.
People's names are all mapped in Unicode code points.
People's names are case sensitive.
People's names are case insensitive.
People's names sometimes have prefixes or suffixes, but you can safely ignore those.
People's names do not contain numbers.
People's names are not written in ALL CAPS.
People's names are not written in all lower case letters.
People's names have an order to them.  Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
People's first names and last names are, by necessity, different.
People have last names, family names, or anything else which is shared by folks recognized as their relatives.
People's names are globally unique.
People's names are almost globally unique.
Alright alright but surely people's names are diverse enough such that no million people share the same name.
My system will never have to deal with names from China.
Or Japan.
Or Korea.
Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have "weird" naming schemes in common use.
That Klingon Empire thing was a joke, right?
Confound your cultural relativism!  People in my society, at least, agree on one commonly accepted standard for names.
There exists an algorithm which transforms names and can be reversed losslessly.  (Yes, yes, you can do it if your algorithm returns the input.  You get a gold star.)
I can safely assume that this dictionary of bad words contains no people's names in it.
People's names are assigned at birth.
OK, maybe not at birth, but at least pretty close to birth.
Alright, alright, within a year or so of birth.
Five years?
You're kidding me, right?
Two different systems containing data about the same person will use the same name for that person.
Two different data entry operators, given a person's name, will by necessity enter bitwise equivalent strings on any single system, if the system is well-designed.
People whose names break my system are weird outliers.  They should have had solid, acceptable names, like 田中太郎.
People have names.

[DDD]

people wanted to know that

[TehBorken]

Falsehoods programmers believe about time...All of these assumptions are wrong.

   The offsets between two time zones will remain constant.
OK, historical oddities aside, the offsets between two time zones won't change in the future.
Changes in the offsets between time zones will occur with plenty of advance notice.
Daylight saving time happens at the same time every year.
Daylight saving time happens at the same time in every time zone.
Daylight saving time always adjusts by an hour.
Months have either 28, 29, 30, or 31 days.
The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.
There is only one calendar system in use at one time.
There is a leap year every year divisible by 4. (http://support.microsoft.com/kb/214326)
Non leap years will never contain a leap day.
It will be easy to calculate the duration of x number of hours and minutes from a particular point in time.
The same month has the same number of days in it everywhere!
Unix time is completely ignorant about anything except seconds.
Unix time is the number of seconds since Jan 1st 1970.
The day before Saturday is always Friday.
Contiguous timezones are no more than an hour apart. (aka we don't need to test what happens to the avionics when you fly over the International Date Line)
Two timezones that differ will differ by an integer number of half hours.
Okay, quarter hours.
Okay, seconds, but it will be a consistent difference if we ignore DST.
If you create two date objects right beside each other, they'll represent the same time. (a fantastic Heisenbug generator)
You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.
If a process runs for n seconds and then terminates, approximately n seconds will have elapsed on the system clock at the time of termination.
Weeks start on Monday.
Days begin in the morning.
Holidays span an integer number of whole days.
The weekend consists of Saturday and Sunday.
It's possible to establish a total ordering on timestamps that is useful outside your system.
The local time offset (from UTC) will not change during office hours.
Thread.sleep(1000) sleeps for 1000 milliseconds.
Thread.sleep(1000) sleeps for >= 1000 milliseconds.
There are 60 seconds in every minute.
Timestamps always advance monotonically. (http://www.metafilter.com/117073/Falsehoods-Programmers-Believe#4405410)
GMT and UTC are the same timezone.
Britain uses GMT.
Time always goes forwards.
The difference between the current time and one week from the current time is always 7 * 86400 seconds.
The difference between two timestamps is an accurate measure of the time that elapsed between them.
24:12:34 is a invalid time
Every integer is a theoretical possible year
If you display a datetime, the displayed time has the same second part as the stored time
Or the same year
But at least the numerical difference between the displayed and stored year will be less than 2
If you have a date in a correct YYYY-MM-DD format, the year consists of four characters
If you merge two dates, by taking the month from the first and the day/year from the second, you get a valid date
But it will work, if both years are leap years
If you take a w3c published algorithm for adding durations to dates, it will work in all cases.
The standard library supports negative years and years above 10000.
Time zones always differ by a whole hour
If you convert a timestamp with millisecond precision to a date time with second precision, you can safely ignore the millisecond fractions
But you can ignore the millisecond fraction, if it is less than 0.5
Two-digit years should be somewhere in the range 1900-2099
If you parse a date time, you can read the numbers character for character, without needing to backtrack
But if you print a date time, you can write the numbers character for character, without needing to backtrack
You will never have to parse a format like ---12Z or P12Y34M56DT78H90M12.345S
There are only 24 time zones
Time zones are always whole hours away from UTC
Daylight Saving Time (DST) starts/ends on the same date everywhere
DST is always an advancement by 1 hour
Reading the client's clock and comparing to UTC is a good way to determine their timezone
The software stack will/won't try to automatically adjust for timezone/DST
My software is only used internally/locally, so I don't have to worry about timezones
My software stack will handle it without me needing to do anything special
I can easily maintain a timezone list myself
All measurements of time on a given clock will occur within the same frame of reference. (http://www.reddit.com/r/programming/comments/v8s0y/falsehoods_programmers_believe_about_time/c52kqpa)
The fact that a date-based function works now means it will work on any date.
Years have 365 or 366 days.
Each calendar date is followed by the next in sequence, without skipping.
A given date and/or time unambiguously identifies a unique moment.
Leap years occur every 4 years.
You can determine the time zone from the state/province.
You can determine the time zone from the city/town.
Time passes at the same speed on top of a mountain and at the bottom of a valley.
One hour is as long as the next in all time systems.
You can calculate when leap seconds will be added.
The precision of the data type returned by a getCurrentTime() function is the same as the precision of that function.
Two subsequent calls to a getCurrentTime() function will return distinct results.
The second of two subsequent calls to a getCurrentTime() function will return a larger result.