One of the things I run into often is problems caused by programs which don't conform to ISO standardss.

One example would be not using the ISO country tables but making up their own shorthands, which goes okay for the United States (US), or the Netherlands (NL) but goes spectacularly wrong for the United Kingdom (GB, not UK) or Spain (ES, not SP) and a lot of other countries.

As another example, internal date notations. Why would anyone store a date as 01/02/2014 ever? It is completely unclear whether that is 1st February or January 2nd, whereas if you use the ISO standard you just store 2014-02-01* and it's unambiguously February 1st.

My question: When and why should a programmer make up their own constructs when there is an ISO standard available?

* Store 2014-02-01, and format the date accordingly when showing it to an end user.

  • 64
    Because they don't know them, or forgot about them! There are gazillions of ISO standards.... Do you know all of ISO26262? Commented Jul 25, 2014 at 9:21
  • 11
    Usually a lack of experience as a programmer makes you do things of which you don't realise what the consequences are. Generally a quick "I'll just do it like this" is thought of instantly without any evaluation on whether there's already something existing for it or not.
    – dammkewl
    Commented Jul 25, 2014 at 9:21
  • 13
    Also, many ISO standards are not that easy to find (usually they cost big bucks, and finding the latest draft is not that easy!). Commented Jul 25, 2014 at 9:24
  • 64
    The great thing about standards is that there are so many to choose from! Commented Jul 25, 2014 at 11:27
  • 5
    Among the weirdest things are programs that force a non-english on a non-english locale user to change his local system-wide settings to decimal points in order to work correctly. Not to speak of programs that refuse to work or simply produce garbage under non-english charsets (russian, japanese, greek), let alone RTL systems (hebrew, arabic). There's some ignorance involved, I guess.
    – JensG
    Commented Jul 25, 2014 at 13:28

13 Answers 13


Never attribute to malice that which is adequately explained by stupidity. -- Robert J Hanlon.

That, and a lack of communication.

So, it's not a conspiracy of anti-ISO sentiment making people think "I know, I'll use UK instead of GB", nor is it an inclination that "they know better", or even a sense that the standard is no good. It'll be entirely because they just don't know it is there, and they should use it.

I mean, for some people, if it's not bundled into Visual Studio, it might as well not exist. For some others, maybe they just don't want the full set or it's too difficult to fetch the definitive list, so they just make up their own sub-set to solve their immediate situation. For others, the default is what gets used - so date formatting isn't "formatted in ISO, or even country locale", it's "formatted in whatever comes out" and if that suits them, then it's job done (this is usually a criticism of American programmers).

  • 20
    It doesn't help that a lot of ISO standards are expensive and/or hard to obtain... Even if you badly want to! Commented Jul 25, 2014 at 18:11
  • yyyy-mm-dd ... is not expensive
    – halfbit
    Commented Jul 26, 2014 at 9:05
  • 12
    @halfbit: Expensive to purchase, not expensive in computational resources. Seriously, browse their store. You want the floating-point standard? That'll be 178 francs. Commented Jul 26, 2014 at 9:56

When I program in Ruby, I generally always ignore the ISO Ruby standard. Why? Because it's incredibly restrictive! ISO Ruby is a minimal subset of the intersection of Ruby 1.8 and Ruby 1.9. The current version of Ruby, which is supported by all Ruby implementations (or at least will be very soon) is Ruby 2.1, and it has many features that make programming easier. Programming in ISO Ruby is a PITA.

When I program in C#, I also ignore ISO C#, which is a subset of C# 2.0 (and more importantly, the ISO Class Library is an extremely small subset of the .NET BCL), and instead I program in C# 5.0 and I don't restrict myself to use only the libraries which are specified in the ISO CLI, instead I use the common subset of libraries available in .NET 4.5.2 and Mono 3.4.0.

And when doing web design, I very much prefer to use HTML5 over ISO HTML (which is a small subset of HTML 4.01 Strict), again, because HTML5 is much more feature-rich than a restricted subset of an ancient version of HTML.

So, there are good reasons for ignoring ISO standards.

  • 9
    It depends, with C, C++, Fortran... the situation is very different. Commented Jul 25, 2014 at 13:31
  • 1
    This seem less like "ignoring" as the question intends, and more like "choosing a tool that does what you need". If you need C# 5.0 features, it makes no more sense to use ISO C# than it would to use ISO C, or ISO Fortran; that's simply not the tool you asked for, and ISO doesn't have an equivalent. Your example also still involves sticking to well-defined standards, just not ISO ones. Commented Jul 25, 2014 at 13:48
  • 3
    @Leushenko I disagree; the OP seems to think you should always follow ISO standards, period. +1 for a brazen counterexample to this "should".
    – djechlin
    Commented Jul 25, 2014 at 15:33
  • 3
    All well and good, but I think the question was really talking about ISO standards for data representation, not ISO standards for programming languages.
    – Aaronaught
    Commented Jul 25, 2014 at 16:39
  • 4
    Some argue that (some) ISO Standards are a perfect example of the "Design by Committee" anti-pattern... Commented Jul 25, 2014 at 18:15

Per your example, "GB" is the country code for the United Kingdom. However, "UK" was the at one time the MARC (US Library of Congress) standard code, although I believe that's deprecated. And the IANA uses .uk for the top-level domain for the United Kingdom.

So, if something doesn't conform to an ISO standard, it doesn't mean that no standard is being used; it may simply mean that a different standard is being used. (As @Jörg noted in a comment, the nice thing about standards is that there are so many to choose from.) In which case the question really becomes which standard would be most appropriate for the given problem domain, environment, etc.?

Responses to that question would probably be largely opinion-based and quickly degenerate into a "religious" debate. But ISO standard conformance isn't necessarily always the best answer. For example, if a piece of software needs to interface with library databases, MARC standards might be a more appropriate choice than ISO. If most of your organization's software does things a certain way, you might want to stick with that approach, at least in the short-term -- it's your organization's "standard", after all.

Also, standards do evolve/change. What was conformant yesterday may not be today.

And, while I wouldn't want to rule out ignorance and/or sloth as the cause of the issues you point out ... the developer might simply not have had enough time to address them.


Compliance with an ISO standard is not always a cost-free activity. If a particular standard isn't already implemented in the toolkit she's using, a programmer is faced with a necessary choice: Is it cheaper to properly implement this now, or not implement the standard and deal with conversions later?

It's easy to say "hey, you should always implement the standard", but everything has a cost. And there are some good reasons why a programmer may not want to implement an ISO standard.

  • The customer may be following a proprietary or non-ISO standard. Better to hew to the standard a customer is expecting than leave unintended headaches for your successor by hiding an additional implementation besides what the customer wants and your language requires.
  • There may be a great deal of existing data, and a conversion or format-break may not yet be feasible. If you have twenty years of customer contacts and contracts keyed with local date-times, you don't necessarily want to change all those hundreds of millions of fields to ISO standard dates until you can do it right.
  • Adherence to the standard may impose a greater cost than the benefit provides. If you're dealing with entries entirely within the United States, for example, the five-character ISO-3166-2 code (US-NY) is three unneeded characters over the standard US postal code (NY).
  • 1
    Agile processes aside, it's always cheaper to include any feature - including an ISO standard - during the design/specification phase than it is during the implementation/maintenance phase, because the design phase only represents 10% of the work. This is just an inversion of the law of diminishing returns - similar to how identifying and fixing a defect in production can cost up to 10x more than if it was found as a result of unit test or acceptance test. If you have a solid reason for not using the ISO standard at all, that's fine; if you say you'll implement it later, you're lying.
    – Aaronaught
    Commented Jul 25, 2014 at 22:40
  • @Aaronaught: Do you think I should clarify that by "conversion" I meant an external file conversion, rather than an internal re-write?
    – DougM
    Commented Jul 26, 2014 at 15:13
  • If that's what you meant, then certainly I would clarify. It's normally not that simple, as ISO defines more standards for data types than file types, and many if not most developers deal with applications that don't deal with documents or "files" per se. If, for example, you store a non-ISO date or country code in a database (and don't store the corresponding ISO date or country code), then the cost of conversion down the road is going to be very high. On the other hand, if you're simply talking about importing some industry-specific file type, then sure, you can do that whenever.
    – Aaronaught
    Commented Jul 26, 2014 at 15:48
  • +1 "... you don't necessarily want to change all those hundreds of millions of fields ... until you can do it right." Exactly.
    – David
    Commented Jul 28, 2014 at 12:17

In the case of inexperienced programmers/database designers, it's because of not knowing. They tend to reinvent the wheel because they don't know a group of people spanning industries, already discussed the issue and came up with an standard approved by all who participated, often after very long discussions, revisions, etc. Recently a co-worker of mine showed incredulity when I told him there was an ISO standard regarding whether a given week is considered the last week of a year or the first one of the next year (ISO 8601). He didn't believe a standard existed regarding something so specific. I told him that the correctness of many applications depended on that standard.

In the case of experienced programmers/database designers, it's disregard caused by "knowing better", not-invented-here syndrome, and/or grandiosity. They don't trust ISO or any other standard bodies because they consider the ISO code is "not stable enough", meaning it will change someday. So they create their own, invented-here or auto incremented codes/identifiers hindering interoperability, which they also disregard. See this similar question, albeight database-design inclined. They give reasons like:

I may not necessarily want my database design to depend on a bunch of third parties (IATA, ISO), regardless of how stable their standards are. Or, I may not want to depend on a particular standard at all.

enter image description here

Oddly enough those who disregard standards use standard USB ports, buy standard-sized DVDs and BluRays and drive cars with tires that conform to standards.

  • 12
    -1 for your caricature of experienced, anti-ISO programmers.
    – djechlin
    Commented Jul 25, 2014 at 15:39
  • 4
    @djechlin The phrases in quotes are literal ones from real answers in the question linked. You can even search in the page to see those are real opinions. Also not all experienced programmers hate standards. Commented Jul 25, 2014 at 15:55
  • 2
    @djechlin In my answer there's a linked question, look for "see this similar question". The word "question" has a link. There you can search for the exact phrases in quotes. Commented Jul 25, 2014 at 16:01
  • 2
    @djechlin the link is in the answer, not the question, here you have it: programmers.stackexchange.com/questions/204340/… Commented Jul 25, 2014 at 16:04
  • 5
    On the flip side, the person who wrote this answer is misrepresenting the linked question; the issue there wasn't with people not wanting to use the standards, but with depending on the stability of a particular standard as a primary key. Most experienced database designers today will try to steer you away from "natural keys", period, because they almost inevitably turn out to be less natural than you'd originally assumed. That's simply an argument for decoupling the physical database design from the logical data - nobody said not to use the standards at all.
    – Aaronaught
    Commented Jul 25, 2014 at 22:33

Well, people tend to ignore ISO standards: for example, you wrote

if you use the ISO standard you just store 20140201* and it's unambiguously February 1st.

but the fully ISO8601-compliant rendition is in fact 2014-02-01. (see also xkcd 1179)

  • 7
    The ISO8601 standard allows both the YYYY-MM-DD and YYYYMMDD formats for complete calendar date representations.
    – Pieter B
    Commented Jul 25, 2014 at 14:20
  • 8
    ISO allows for basic and extended format, both of these are fully compliant.
    – Pieter B
    Commented Jul 25, 2014 at 14:34
  • 10
    ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04. classic
    – WernerCD
    Commented Jul 25, 2014 at 17:05

One of the reasons is that the application domain and the users might not use these standards themselves. Even when some domains use some standards, some of them might have made different choices than the ISO standards, often for historical reasons.

If your users already use "UK" in their existing procedures(1) to refer to "United Kingdom of Great Britain and Northern Ireland", it doesn't necessarily make sense to use "GB" in their data structures (especially if what you mean by country isn't quite an "ISO" country, e.g. separating UK nations or having subtle differences with the Channel Islands and so on). Of course, you could have a mapping between internal storage a presentation, but sometimes, it's a bit over the top. You're rarely programming for the sake of programming, you often have to adapt to your environment.(2)

You also have to remember that these standards have evolved in parallel with software. You often have to develop within the context of other pieces of software, some of which may be imperfectly designed, some of which may still be affected by legacy decisions.

Even if you look at internal data storage formats, some ambiguities are hard to resolve. For example, as far as I know, Excel uses a decimal number to represent timestamps: it uses an integer as the number of days since a reference date, then what's after the decimal represents the fraction of the 24 hours to give you the hour... The problem is that this prevents you from taking into account time zones or daylight saving time (23h or 25h in a day), and Excel will convert any date/time to that internal format by default. Whether you want to use the ISO format or not becomes irrelevant if another piece of software you have to work with doesn't leave you a choice.

(1) I don't mean "programming procedures" here.

(2) Don't ask me why people don't use those standards in their daily lives either. I mean YYYYmmdd is clear, dd/mm/YYYY is clear, but ordering a date with medium, small, big order of granularity like mm/dd/YYYY, that just doesn't make sense :-) .

  • 1
    Ha! You know what doesn't make sense? Commas where decimals should be! ;) Commented Jul 25, 2014 at 13:41
  • @Darkwater23 Ha, I don't mind that one either way, it's just a convention and it doesn't need to make sense. It's just that I've always found that mm/dd/YYYY seemed to lack logic altogether, why not go as far as mm-MM-dd-HH-YYYY for timestamps ;-) But hey, I agree, that's just the way it is, so we have to live with it.
    – Bruno
    Commented Jul 25, 2014 at 13:51
  • 2
    @Darkwater23 Actually, an ISO standard uses a weird unicode symbol (this: ) for decimal separator on keyboards, and I thought plain tick marks (') were standardized for digit grouping as well (although I can't find it now)
    – Izkata
    Commented Jul 25, 2014 at 18:57
  • +1 for pointing out another reason that daylight-saving is a wast of time. Commented Jul 26, 2014 at 8:44
  • 1
    @richard I don't necessarily mind DST either way, but surely programmers should aim to store their timestamps with timezone information as much as possible. It's not uncommon for an application to be used across multiple time zones (independently of DST) anyway, making sure you leave as little room for ambiguity when you store a time stamp should be part of the initial design. (It might not be always applicable, but in doubt, it's always worth taking it into account.) Of course, it's a complicated problem (not just +01 hour for example, but the locality can matter too, depending on the use).
    – Bruno
    Commented Jul 26, 2014 at 13:15

Why would I not use ISO 3166-1 alpha-2 country codes?

Because I use STANAG 1059 country codes... and in that UK is the code for the United Kingdom (instead of GB as per ISO 3166-1).

Alternatively I could use the FIPS country codes - again UK is the country code for the United Kingdom.

There are many standards (ISO and non-ISO) and sometimes a particular domain uses/demands a standard which is incompatible with the ISO standard.


Storing 20140201 is not unambiguous at all. Only when you include the knowledge that is following the ISO standard does it become unambiguous. The same goes for 01/02/2014: when you include the knowledge that the format is mm/dd/yyyy it is also perfectly unambiguous.

As long as the application does not have to interface with other application any well documented standard can work just as fine.

There is a tradeoff between what is easy for humans (I tend to use 1-2-2014) and computers (who would even be better of with a binary representation instead of ISO). Novice programmers tend to stick with what they can easily understand, more experiences programmers start to see the advantages of computer-oriented storage.

  • 4
    Agreed. I would be more concerned with ISO if I was writing an application for international consumption. My apps for Middle America don't need the overhead or restrictions. Commented Jul 25, 2014 at 13:37
  • 4
    By writing "As long as the application does not have to interface with other application" you've given a strong reason to use the ISO standard. Commented Jul 25, 2014 at 14:18
  • 5
    Your profile doesn't list your location, so I don't know whether your sample date is in January or February.
    – djechlin
    Commented Jul 25, 2014 at 15:35
  • 6
    -1 for assuming won't interface with other applications. This is contrary to the entire programming industry.
    – djechlin
    Commented Jul 25, 2014 at 15:41
  • 18
    @Jeff: I have NEVER EVER seen a date coded as YYYYDDMM for any purpose other than to claim such a coding is possible. Have you?
    – supercat
    Commented Jul 25, 2014 at 16:30

A point not raised so far is the cultural appropriateness of international standards.

Consider the international standard for measurements. Let's present those to users in the United States. I'm not sure all your US users will be happy about kilometres, kilograms, and litres.

Consider that international standards are written by governments. If the government of Spain chooses not to recognise the Basque language then how does it get a ISO specification? This is particularly an issue with the dialects and creoles of marginalised groups.

Even country codes can be problematic: does the Crimea now get its own country code? Formulas are eventually found (eg, "Former Yugoslav Republic of Macedonia") but your application may need some stand-in until the diplomacy or war comes to an end.

Consider that international standards are written with particular applications in mind. These may not entirely fit your application. For example, if you are storing language with a view to sending letters then you may wish to code the blind distinctly, even if they are proficient in speaking, say, US English. Statistics organisations are well aware of the need for specifying the exact meaning of a variable (aka the variable's "meta data") as they encounter every possible edge case during a population census. Some of that rigour is well worthwhile for database fields.

The final point is that in making these sort of choices your program may be making a political statement. This reality can mess with the nicest of code (eg, you may need multiple language names for the same language).

  • I believe most blind people would be able to get someone to read a letter to them. It's not like you'd be the first person (or company) to send them a letter.
    – Wildcard
    Commented Jun 14, 2016 at 19:00

In my experience programmers fail to use ISO standards for a variety of stated reasons, e.g.:

  • "I didn't know that there was an ISO standard" (ceases to be a valid reason once you're told!)
  • "The standard is inaccessible (can't find /afford a copy)" (really??)
  • "The standard is too restrictive" (usually if the standard says "don't" then there's a good reason. Ignore it at your, and your customer's, peril!)
  • "The standard doesn't include the latest functionality / library" (no standard includes EVERY library that you'll ever want to use so adhere to the standard for the things that it DOES include/cover and be consistent with the standard for the things that it doesn't)
  • "The standard is too cumbersome to implement" (greatly over-used excuse but see below)

The only reason that I accept from my staff, as not being a lame excuse, is "the standard really isn't a good 'fit'" - backed up by evidence. Sometimes the complexity of the the applicable ISO standard is out of proportion to the problem / solution. Sometimes the context in which you will implement your solution is significantly different from that assumed by the standard. And sometimes the standard can be improved upon - that is how progress happens.

More often than not though, the failure to use the ISO standard can be attributed to inexperience, laziness or arrogance. I regret to say that English-speaking programmers are particularly guilty of laziness as regards internationalisation and that our US colleagues tend to perceive ISO as "an irrelevant European thing" (apologies to the minority to whom this does not apply).

  • 5
    It isn't necessarily an irrelevant European thing, it is an irrelevant unless you need to inter-operate with someone who follows them. How often do Europeans follow ANSI standards without a reason other than hey look a standard?
    – stonemetal
    Commented Jul 25, 2014 at 17:03

ISO has lots of standards. As did CCITT/ITU. Some of these standards are "aspirational" standards, while other are minimum required functionality. It's not often clear which is which.

I remember in the 1980s asking why some equipment vendors implement one subset of the standard while other vendors implement a different subset. That's when it came out that the standards are often set before something works. And vendors often deliberately choose not to implement standards so that they can hamper interoperability, which then grants them an advantage.

That's why I like IETF RFCs. They don't even become RFCs until there are 3 independent implementations of the RFC.

  • 2
    The "rough consensus and running code" model of the IETF was well abandoned since at least as early as 1995. I was too involved in the IETF in that era and the model was "a spec that I sneezed out and not even a reference implementation". It was nice when the "running code" standard was in place instead of figuring out how to implement a wholly under-specified protocol and make it work with other implementations that had to guess as much as you did.
    – msw
    Commented Jul 25, 2014 at 18:28
  • 1
    When I started using IETF RFCs, I used the ones developed well before 1995. The running code specs are the best. Otherwise you end up with too many ivory-tower chartware engineers dreaming up specs without the responsibility of making them run.
    – Jay Godse
    Commented Jul 26, 2014 at 22:03

If I'm building an Oracle database, and I want to store dates, I'm going to use the Oracle DATE datatype. I won't know, or care, whether or not Oracle conforms to the ISO standard. This is really a case of my conformance to a different standard (the Oracle one) and not so much departure from the ISO standard. See @David's response.

In some cases, by the time I realized there was an ISO standard for something I had designed, the cost of going back and redesigning would have been prohibitive, or at least was seen that way.

In the short term, more working code is produced by using available standards or by inventing new ones than by careful research into extant standards. The downside occurs when large scale integration requires interoperability. This almost always occurs in the context of a later project.

  • 1
    I'm not familiar with Oracle, but when using SQL Server or MySQL I too of course use their respective date datatypes when storing dates. But when writing queries with dates, they both recognize yyyymmdd very well where it's hit or miss when you use a locale date.
    – Pieter B
    Commented Jul 26, 2014 at 18:52
  • That's a good point. The standard for the storage and the standard for the interface could be different. Commented Jul 26, 2014 at 23:13

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