I don't specifically mean date-related issues like 2038, but more generally, bugs that fit the pattern:

  • A generation ago, programmers tended to write code that ass-u-me-d X, which was reasonable at the time.
  • But circumstances have changed, and now X is a common source of problems that need to be fixed.

For example:

  • X = "Memory is too expensive to justify storing all 4 digits of the year. Don't worry about 2000; that's a long way off." (broken by Y2K)
  • X = "Who needs size_t? We can just use unsigned int." (broken by 64-bit systems)

closed as not constructive by user8 Nov 28 '11 at 16:12

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 8
    I didn't realize that it said "assumed". :) – Mateen Ulhaq Mar 29 '11 at 7:11
  • 19
    The spelling comes from an American idiom: "when you assume, you make an ass out of u and me" – Berin Loritsch Mar 29 '11 at 12:51
  • 2
    I still don't think two-digit years were inspired by memory issues so much as punch card issues. Four digits were not a big user of memory, but pushing a card layout beyond 72 or 80 columns was a very big deal. – David Thornley Mar 29 '11 at 14:17
  • Solvage: store year numbers in strings. – rightfold Mar 29 '11 at 19:50
  • This can be generalized to "range of variable underdesigned", or "variable out of range, but legitimate". It's a very common design flaw. Designing for the worst imaginable case brings on problems of its own. Deciding what is the proper range of valid inputs for a program is one of the biggest decisions software designers get to make. – Walter Mitty Mar 30 '11 at 11:09

24 Answers 24


IPV4 only networking code. The time hasn't come for most people yet, but the idea of IPV4 only networking will become obsolete.

  • 1
    doh, posted at the same time as mine :) – jwenting Mar 29 '11 at 6:59
  • 6
    @jwenting, not quite the same time, I posted 7 mins earlier. – dan_waterworth Mar 29 '11 at 7:06
  • 1
    I got a message another answer was posted about a second before I pressed the button to post. Something must be off with the timestamping :) – jwenting Mar 29 '11 at 7:43
  • It takes a while for the system to tell you that another comment has been posted. It probably only checks to see every once in a while. – GendoIkari Mar 29 '11 at 20:26

Many localization issues fit this pattern:

  • a generation ago, programmers assumed all characters can be represented with an 8 bit data type
  • a generation ago, programmers assumed every kind of text should be read left-to-right, top-down
  • a generation ago, programmers assumed the field separator in a CSV file is always the comma character , (No, it really isn't. CSV is the file extension, not the file format specification. My guess is, when CSV was invented, it actually was just comma separated values. As it evolved, nobody wanted to rename it to "tabular data file with locale-dependent column separator, quoted fields for field values containing a separator character and double quotes for quote characters".)
  • 13
    +10 if I could. Even today, developers assume these things. – dan_waterworth Mar 29 '11 at 8:21
  • 12
    Well, the separator in a comma-separated-values file IS the comma character. That kind of follows from the term... :) – a CVn Mar 29 '11 at 11:54
  • 23
    @nikie: If the separator is not a comma, then it's not a COMMA-separated values file. Clear as mud? ;-) – a CVn Mar 29 '11 at 12:00
  • 11
    @nikie, "Word" is just the name of a rich-text editor; not really the same thing. – David Murdoch Mar 29 '11 at 12:58
  • 4
    @nikie: The RFC 4180 text/csv format (which is what the Wikipedia examples describe) is not localized; it specifically requires commas. – dan04 Mar 30 '11 at 0:14

Validators for domain names making wrong assumptions like:

  • TLD is 2-3 characters long (not true since 2001);
  • domain names and TLDs contain only US-ASCII characters (not true since January 2010);
  • 5
    I got found this bug in RedBox kiosks. I can't use .NAME or .ME for an email address. – Mike Wills Mar 29 '11 at 14:29
  • Or requiring more than zero domain levels at all. . is a valid domain! – rightfold Mar 29 '11 at 19:52
  • in fact it's never been true according to the specs, only (possibly) in practice... – jwenting Mar 30 '11 at 9:48
  • @jwenting: right, but until 2001 it was true in practice – vartec Mar 30 '11 at 9:49

I did some research on y2010 about 14 months ago:

printf("200%d", year);

Believe it or not, code like that exists.

  • +1 for the SpamAssassin Y2K10 bug: taint.org/2010/01/04/003841a.html – Ciaran Mar 29 '11 at 9:29
  • +1. I found a y2010 bug in the code I was working on at the time it ticked over (not mine). – Bobby Tables Mar 29 '11 at 11:00
  • 6
    The clocks in all the big, expensive copying machines here at work had to be reset to 2005, since the machines didn't work after new year 2011. – Thomas Padron-McCarthy Mar 29 '11 at 12:48
  • 3
    when fixing y2k bugs, often we were told to write code assuming any year before (for example) 20 or 30 was 21xx, any date after 20xx. Most of those only exist in conversion scripts, but some exist in code retrieving actual legacy data. Going to get funny in 2020 to 2030 when that code (if still in use) starts rolling over, as all we did was postpone the problem by a few decades (on customer orders, them wanting the quick and dirty solution that didn't change the database). – jwenting Mar 29 '11 at 12:59
  • 2
    oops :) Thinking ahead again, trying to solve the y2.1k problem. – jwenting Mar 30 '11 at 6:23

Another one not yet touched on are applications (and especially websites) assuming that all addresses are US addresses. In an era where international business is increasingly vital, this is causing trouble. Companies are loosing out on possibly lucrative business because customers find themselves incapable of placing orders.

This is especially critical with postal codes/zip codes and phone numbers. Numerous applications and websites validate these against the US system, incorrectly assuming that's the only system that exists (when in fact a lot of the planet uses different systems, and there are countries without any postal codes). A smaller problem is demanding house numbers in addresses, when there are still locations without them (small villages) and sometimes even street names.

Heard a story last year about someone in a small village in France trying to order a phoneline installed (he was just moving there) and finding it impossible as the computerised system used by the provider wouldn't accept his address which existed only of the name of the house and village (no street name, no house number, no postal code).

  • In 2005 the Atlantic island Tristan da Cunha was allocated a postal code by the Royal Mail specifically so that it was easier for residents there to make online purchases. Delivery may take a couple of months so no point in paying for priority shipping! news.bbc.co.uk/1/hi/uk/4129636.stm – uɐɪ Mar 29 '11 at 14:45
  • 8
    I'd say this is mostly due to lazyiness or budget since address validation is very complex. When looking for guidelines on the subject you will likely see someone telling you "It depends on what you need to accomplish." And it just so happens that, for U.S. localized applications/businesses, a U.S. address is all that will be needed (well, most of the time). This kinda reminds me of the saying that "with unlimited time and resources every computer program will eventually grow complex enough to send email". – David Murdoch Mar 29 '11 at 15:40
  • I had the same problem in Canada a few years ago trying to open a bank account with an institution which did not have a local branch. They simply had no way to enter "Km 187.3 Such-n-such Highway" as a valid address. At least we didn't have the same problems with utilties like phone, fuel, electricity. – matt wilkie Mar 29 '11 at 19:19
  • Unless the programmer has done something dumb like made the "zipcode" a mandatory 5 digit field (Post codes in AUS for instance are 4 digits) or not offered a state value of Other in the US states dropdown, then this is not really an issue. – Anonymous Type Mar 29 '11 at 23:33
  • It doesn't get really bad until the form also check that the zip code is in use in the US, at that point one can't simply enter something like 12345. – aaaaaaaaaaaa Mar 29 '11 at 23:54

Single-byte encoding (ASCII, ISO-8859-x) vs multi-byte encoding (Unicode, UTF-8). That's currently the biggest legacy issue I can think of. There is just so much software that assumes that strings' byte length == character length.

  • Life gets fun putting unicode onto things like serial terminals. – quickly_now Mar 30 '11 at 6:41

IPv4 comes to mind. We're running out of IP addresses (in fact it may already have run out, the last batches have been distributed to regional authorities).

Introduction of the replacement IPv6 is slow as hardware and software manufacturers are catching up.

  • 7
    As an aside, the grey market for IP addresses has already sprung up. Microsoft were the first to get into the game, spending $7.5m to buy 666,624 IPv4 addresses from bankrupt Nortel: * theregister.co.uk/2011/03/24/microsoft_ip_spend – Ciaran Mar 29 '11 at 7:17
  • 2
    Duplicate answer - programmers.stackexchange.com/questions/63131/… – ChrisF Mar 29 '11 at 11:48
  • 1
    posted at the same time, Chris :) Two minds coming up with the same idea at the same time... – jwenting Mar 29 '11 at 12:56
  • Not entirely true - with NAT and other technologies, IPv4 is being extended beyond its limits. But the assumption that there is only IPv4 is a 'y2k' – HorusKol Mar 29 '11 at 22:38

Something that got me royally badly a few months ago was cookie expiration dates...

Apparently, cookie expiration dates can be set only so far forward into the future (correct me if I'm wrong on this point - not an expert on this myself!). Anyway, a few months ago a really bizarro login problem came up with an app that our team was maintaining. But, this was a side-project, and this login component was really solid, didn't have to be touched in 10 years, so nobody was around who even knew how it worked (never had to touch it for how solid it was).

Anyways - after half a day of digging around and losing my mind I noticed there was a hard-coded date of 31st December 2010 in a validation routine. So basically anyone who was trying to use the system with a newer cookie couldn't log in. Turned out this was hard-coded way back in 2001, because they couldn't set a cookie expiration date beyond 10 years into the future - and the programmer at the time was too lazy to make it a "floating date".

  • 1
    So much for "really solid"! :) – Max Mar 29 '11 at 12:08
  • You do can set cookie expiration to the past for the browser to remove the Cookie. – mauris Mar 29 '11 at 12:57
  • 4
    I'm not sure if this is a real restriction. "Permanent" cookies often set with end-of-unix-epoch expirations (2038). – Yahel Mar 29 '11 at 15:08
  • @yc01, we'll see in 2039. – user1249 Apr 24 '11 at 12:08

Doing any kind of date arithmetic (addition/subtraction) directly on a UNIX Epoch time integer, for example:

March 29, 2011 11:13:39 GMT

and you want to figure out the correct time for the east coast of America, EST (-5:00 GMT), so you do something like:

March 29, 2011 06:13:39 EST

which is WRONG, because March 29, 2011 happens to be EDT (-4:00 GMT).

This isn't so much a Y2K caliber bug, as you don't have to wait 10 years to see its affect, but, say you hire a contract programmer who is only working on the project for a month or so, then, BAM! the thing breaks after daylight savings time ends.

  • 31
    The mere existence of daylight saving time is the real bug here. – Greg Hewgill Mar 29 '11 at 18:29
  • 3
    Think of the farmers... won't somebody think of the farmers?! – Jake McGraw Mar 29 '11 at 19:55
  • That code is accurate for EST. If you want EST5EDT then code for that, but if you just want EST then subtracting 5 hours works. – Sparr Mar 29 '11 at 20:27
  • 3
    @jakemcgraw: Actually, DST was an urbanite idea. Farmers schedule their lives around the sun, not the clock. – dan04 Mar 30 '11 at 0:17
  • 1
    @dan04 exactly nobody thinks of the farmers – Jake McGraw Mar 30 '11 at 10:46


Storing unhashed passwords, leaving "back doors" in applications, using languages that have buffer overflows. See the OWASP top 10 for the current list of dumb assumptions.

  • 10
    -1. This question isn't about dumb assumptions, it is about valid assumptions that were invalidated by changing circumstances. Like the assumption that nobody is going to run a program unmodified for 40 years. – Jörg W Mittag Mar 29 '11 at 10:49
  • 1
    @Jörg W Mittag: I though the Y2K assumptions were "dumb". And I was there -- in the 70's and 80's -- being asked to write code with 2-digit years. I don't see how you can distinguish between date assumptions and security assumptions calling one dumber than the other. What rule do you use? – S.Lott Mar 29 '11 at 11:14
  • 1
    What assumptions are being made regarding unhashed passwords? I'd argue that storing unhashed passwords is due to extreme ignorance. – David Murdoch Mar 29 '11 at 13:02
  • 1
    ^ That's reaching quite a bit. – user13280 Mar 29 '11 at 15:35
  • 1
    @Chevex: Time will tell, won't it? Already people look at poor security assumptions and call them "dumb". Not so long ago, they were just assumptions. – S.Lott Mar 29 '11 at 15:41

Timezone support and usage. How many systems have you seen that just have dateStarted or dateCreated without any acknowledgement or notation on which timezone is considered the base? Hopefully it's GMT/UTC but counting on that is risky at best.

  • 1
    A PC's BIOS clock is a good example of such a system. – dan04 Mar 30 '11 at 0:18

Developers - or DBA's - who assume that everyone's name falls into the familiar (to western eyes) pattern of FirstName and LastName.

  • In many Asian countries, the name of the family traditionally comes first because of a cultural value that places the needs of the family over the needs of the individual. Writing "Bevan Arps" can be considered disrespectful, even rude.

  • In other parts of the world, families don't have names - people are referred to by their (only) name. If there might be confusion, their parents or trade are referenced as well.
    [Aside: This is also the source of many western family names like McGreggor (son of Greggor), Mathieson (son of Mathie), O'Connor (son of Connor), Carpenter, Smith, Butcher and Taylor.]

  • Not everyones name has a long spelling - "N" and "O" are the english spellings of genuine names, but many systems reject the names as too short.

  • Not everyone's surname is short enough to fit into a 50 character field either.

  • Not everyone's name gets capitalised the same way. Some people write their surname "van den ..." others "Van Den ..." and adjusting it is wrong.


In the UK when the VAT rate changed from 17.5% to 15% in December 2008 it was the first change to VAT since 1991 and a lot of programs had the value hard coded into them.

The change also meant that the system had to separate out VAT rates based on date, because it wasn't going to be just as simple as changing a constant value somewhere.

Hopefully they were all ready when it changed back (and then increased)!

  • +1: I've written variable vat handling more than once. We're aware it needs to happen because here (in Ireland) vat rates go up and down like a hoors knickers. – Binary Worrier Mar 30 '11 at 10:25

One assumption is that our business won't have to grow to non-US (or non-English-speaking) markets. Internationalization when you've done everything right to begin with is a big project. When most of your strings are hard-coded into the code, it's a much bigger project.

There's also assumptions that people make regarding languages.

You can convert between upper and lower case freely (broken in German, with the beta-like eszet character converting into two uppercase Ss).

You have singular and plural forms (some languages have dual forms in addition).

A non-modifier keypress produces a character (friend of mine got hit by a problem that happened when hitting ESC after typing a consonant to form the first part of a Japanese syllable, as katakana and hiragana are syllable alphabets).


Not using an XML library to write XML.

The level of frustration you get when dealing with malformed XML files can sometimes be too much. print "<data>$value</data>"; will most likely fail.

There are so many XML libraries out there that you are bound to find one easy to use. Seriously - stop reinventing what others have spent a lot of resources on already. You may think you know XML but more things can go wrong than you may expect.

  • 6
    I'd rather say XML itself is often a major problem :) Having worked on enough projects where it was used only because "it is modern" (even having it forced on us from board level decisions because of that) where it had no added value whatsoever, I've grown wary enough of XML that I'll not use it unless other options are proven not to work. – jwenting Mar 30 '11 at 6:20
  • True for typical desktop and server applications. But sadly, in embedded development, you often have to pay high runtime royalties for simple XML libraries. – nikie Mar 30 '11 at 7:43
  • You don't NEED to use a library as escaping is easy to do (if you remember it). Unfortunately you occasionally don't... – user1249 Apr 24 '11 at 12:11
  • +1, xml isn't a string, it is a node graph that makes an easily readable string. – Wyatt Barnett Sep 23 '11 at 23:19

The programmer's assumption that a user's geographical location should automatically define that user's preferred language. IP-to-location technology should not be used for preferred language decisions.... ever. Even Google and Facebook are guilty of this one.

  • 1
    Surely as an initial guess it's a good start, so long as it's easy to correct when it gets it wrong. – ICR Mar 29 '11 at 22:44
  • 1
    @ICR: AFAIK pretty much all browsers will send an Accept-Language HTTP header, which specifies accepted languages. If your client is telling you something, overriding that means you think you know better than the client what he wants to see. – l0b0 Mar 30 '11 at 9:27
  • @l0b0: Right, that's the way to go, and it's much easier to implement than geolocation, yet many sites don't do it. Also true your second sentence, another example for which is overriding the user's chosen font size, which I see on a vast majority of websites (not anymore, actually, as I have implemented local stylesheets to counter that). – T-Bull May 11 '11 at 15:22

Using an integer to store currency in its least form. Say cent's. Tomorrow you might use a new currency, it happened in many European countries.

Storing static Vat-rates for categories etc in webstores. In many countries vat rates are considered to be static, but the idea is not to have them static and once in a while they are changed.

Storing civic numbers in a specific notation and use it as a key (or any other "natural key" stuff); tomorrow you might have million of refugees from china, will their civic number look like yours? (Today this is already the case in Sweden)

Assuming 0 is NULL in databases. Next SQL-standard might start count from 0, who knows? :-)

  • I heard someone used millicents, which sounds like a nicely convertible unit. Maybe microcents would be more accurate for stock trading, but who's counting, right? – l0b0 Mar 30 '11 at 9:25
  • 4
    Actually it is a good idea to use integers for currency. Otherwise you will only get in trouble with float approximation. – Andrea Mar 30 '11 at 11:50
  • 2
    @Andrea I am not suggesting to use floats in my post. Integers are a bad idea as we have the Decimal and Money fields in databases. – stefan Mar 30 '11 at 18:44

I'm just glad I won't be around for the Y10K apocalypse.


Assuming a primary key derived from application data will never need to be changed. The most common example is user id - it's usually impossible to change, even if the user changes their name.

Other examples I have come across - assuming country codes never change, currency codes, city names.


Serial vs parallel processing. Multi core processors are or will be soon seen as universally ubiquitous, with exception of very product or task specific hardware.


Well, it kind of fits this question, I guess.

Basically, unsecured WiFi networks. Apparently the standards organizations somehow thought something along the lines of "Oh, only good guys will use open WiFi networks!", so they decided to never encrypt it in any way. I mean, isn't that the type of thing that the Diffie-Hellman encryption key exchange was made for?

This is a pretty big problem today, with things like Firesheep being used fairly widely.


Just because Y2K is over doesn't mean programmers are done writing date and time bugs. There were whole families of bugs that struck near and about year 2000. The date and time bugs that continue to arise keep entertaining me in their creativity.

While it's old and becoming dated, the following enjoyed some popularity on the run up to year 2000 and still has some current information.


While legacy hardware my eventually die, legacy data formats live on and on.


32 bits counter in various networking hardware MIBs. They can wrap pretty fast and yet sometime are used for billing...


Not quite the same, but the number 10100401822940525 does not exist in Javascript or ActionScript 3.

Specifically, we found that the number 10100401822940525 appears to simply not exist in these programming environment. You can test this for yourself, simply trace or log the following statements: 10100401822940524 10100401822940525 10100401822940524+1 Number(“10100401822940525″) (10100401822940525).toString()

All of the above statements will output “10100401822940524″, when obviously all but the first one should return “10100401822940525″.

Theres no obvious significance to that value. The binary/hex value isn’t flipping any high level bit, and there are no results for it on google or Wolfram Alpha. Additional testing showed the same result with other numbers in this range.

Mystery solved here:

  • 6
    -1, This answer doesn't fulfil the second criteria, a change of circumstance. – dan_waterworth Mar 29 '11 at 8:19
  • Indeed, hence 'Not quite the same'... – Ciaran Mar 29 '11 at 9:25
  • @Ciaran, That doesn't change the fact that it doesn't really answer the question. – dan_waterworth Mar 29 '11 at 9:35
  • 1
    "I know you asked how to boil an egg, but here's how to make toast!" Nah, I kid, I kid. – Mike Speed Mar 29 '11 at 12:11
  • 3
    Mystery? It's described in ECMA262 8.3 and IEEE 754. It's not a strongly typed language, why do you expect the types to act like strong types? – Incognito Mar 29 '11 at 14:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.