プログラマがISO標準を無視するのはなぜですか？
私がよく遭遇することの1つは、ISO標準に準拠していないプログラムによって引き起こされる問題です。
1つの例は、ISO国テーブルを使用せず、独自の省略表現を作成することです。これは、米国（US）またはオランダ（NL）には問題ありませんが、英国（UKではなくGB）またはスペインには見事に間違っています（SPではなくES）および他の多くの国。
別の例として、内部日付表記。なぜ誰もが01/02/2014として日付を保存するのはなぜですか？それが2月1日なのか1月2日なのかは完全に不明ですが、ISO規格を使用する場合は2014-02-01 *を保存するだけで、2月1日になります。
私の質問：利用可能なISO標準がある場合、プログラマはいつ、なぜ独自の構造を作成する必要がありますか？
* 2014-02-01を保存し、エンドユーザーに表示するときにそれに応じて日付をフォーマットします。
愚かさによって適切に説明される悪意のせいにしないでください。 - Robert J Hanlon 。
それ、そしてコミュニケーションの欠如。
だから、それは反ISO感情の陰謀ではなく、「GBの代わりにUKを使う」と人々に思わせたり、「彼らはよりよく知っている」という傾向や、標準が良くないという感覚でさえありません。彼らがそれがそこにあることを知らないだけで、彼らはそれを使うべきです。
つまり、一部の人々にとって、それが Visual Studio にバンドルされていない場合、存在しない可能性もあります。他の人にとっては、完全なセットを必要としないか、決定的なリストを取得するのが非常に難しいので、直接の状況を解決するために独自のサブセットを作成するだけかもしれません。他の人にとっては、デフォルトが使用されます-したがって、日付のフォーマットは「ISO、または国のロケールでフォーマットされている」のではなく、「出て来るものでフォーマットされている」ので、それがそれらに適している場合は、それが行われます（これは通常、アメリカのプログラマーに対する批判）。
Rubyでプログラミングするとき、私は通常ISO Ruby標準を無視します。なぜですか？信じられないほど制限的だからです！ISO Rubyは、 Ruby 1.8およびRuby 1.9。すべてのRuby実装でサポートされている現在のバージョンのRuby Ruby 2.1、そしてプログラミングを容易にする多くの機能があります。ISOでのプログラミングRubyはPITAです。
C＃でプログラミングするときは、C＃2.0のサブセットであるISO C＃も無視します（さらに重要なことに、ISOクラスライブラリは.NET BCLの非常に小さなサブセットです）。代わりに、C＃5.0でプログラミングして、 ISO CLIで指定されたライブラリのみを使用するように制限するのではなく、.NET 4.5.2およびMono 3.4.0で利用可能なライブラリの共通サブセットを使用します。
また、Webデザインを行う場合、HTML5は古いバージョンのHTMLの制限されたサブセットよりもはるかに機能が豊富であるため、ISO HTML（HTML 4.01 Strictの小さなサブセット）よりもHTML5を使用することを非常に好みます。
したがって、ISO標準を無視することには十分な理由があります。
あなたの例では、「GB」はイギリスの国コードです。ただし、「UK」は、当時はMARC（米国議会図書館）の標準コードでしたが、非推奨であると思います。そしてIANAは.ukは、イギリスのトップレベルドメインです。
したがって、何かがISO標準に準拠していない場合でも、no標準が使用されているという意味ではありません。 different標準が使用されていることを単に意味する場合があります。 （@Jörgがコメントで述べたように、標準についての良い点は、選択できるものが非常に多いということです。）その場合、質問は実際にどの標準が特定の問題のドメイン、環境に最も適切か、など？
その質問への応答は、おそらく大部分が意見に基づくものであり、すぐに「宗教的な」議論に退化するでしょう。しかし、ISO規格への準拠が常に最良の回答であるとは限りません。たとえば、ソフトウェアの一部がライブラリデータベースとやり取りする必要がある場合、MARC標準の方がISOよりも適切な選択かもしれません。組織のソフトウェアの大部分が特定の方法で処理を行う場合、少なくとも短期的にはそのアプローチを使い続けることができます。結局のところ、これは組織の「標準」です。
また、標準は進化/変更されます。昨日適合だったものが今日ではないかもしれません。
そして、私が指摘した問題の原因として無知やナマケモノを除外したくないのですが...開発者がそれらに対処するのに十分な時間がなかっただけかもしれません。
ISO標準への準拠は、必ずしも費用のかからない活動ではありません。特定の標準が彼女が使用しているツールキットにまだ実装されていない場合、プログラマーは必要な選択に直面します：これを適切に実装する方が安いですか、それとも標準を実装せずに後で変換を処理するか？ =
「ねえ、いつも標準を実装すべきだ」と言うのは簡単ですが、すべてにコストがかかります。そして、プログラマーがISO標準の実装を望まない理由はいくつかあります。
- お客様は、独自仕様または非ISO標準に従っている可能性があります。顧客が望むものとあなたの言語が必要とするものに加えて追加の実装を隠すことによって、後継者に意図しない頭痛を残すよりも、顧客が期待する標準に慣れる方が良いです。
- 既存のデータが大量に存在する可能性があり、変換またはフォーマットの変更がまだ実行できない場合があります。現地の日時をキーにした20年の顧客連絡先と契約がある場合、正しく実行できるようになるまで、これらの数億のフィールドすべてをISO標準の日付に変更する必要はありません。
- 標準に準拠すると、メリットが提供するよりもコストが高くなる可能性があります。たとえば、完全に米国内のエントリを扱う場合、5文字のISO-3166-2コード（US-NY）は、標準の米国の郵便コード（NY）よりも3つの不要な文字です。
経験の浅いプログラマ/データベース設計者の場合、それは知らないためです。彼らは、業界にまたがる人々のグループを知らず、すでに問題を議論し、参加者全員が承認した標準を思いついたので、彼らは車輪を再発明する傾向があります。非常に長い議論、改訂などの後で、しばしば特定の週が1年の最後の週と見なされるのか、翌年の最初の週と見なされるのかについてISO標準がある（ ISO 8601 ）と私が言ったとき、私のものは信じられないほどでした。彼は、非常に具体的なものに関して標準が存在するとは考えていませんでした。多くのアプリケーションの正確さはその標準に依存していると私は彼に話しました。
経験豊富なプログラマー/データベースデザイナーの場合、「よく知っている」ではなく無視されます。 -invented-hereシンドローム、および/または壮大さ。彼らは、ISOコードが「十分に安定していない」と考えているため、ISOやその他の標準化団体を信頼していません。そのため、独自の、発明された、または自動インクリメントされたコード/識別子を作成して、相互運用性を妨げますが、これも無視されます。この類似の question を参照してください。彼らは次のような理由を与えます：
標準がどれほど安定しているかに関係なく、私のデータベース設計がサードパーティ（IATA、ISO）の束に依存することを必ずしも望まない場合があります。または、特定の規格にまったく依存したくない場合もあります。
奇妙なことに、標準を無視する人は標準のUSBポートを使用し、標準サイズのDVDとBluRayを購入し、標準に準拠したタイヤで車を運転します。
まあ、人々はISO標準を無視する傾向があります：例えば、あなたは書いた
iSO標準を使用する場合は、20140201 *を格納するだけで、2月1日です。
しかし、完全にISO8601に準拠したレンディションは2014-02-01です。 （以下も参照してください xkcd 1179 ）
その理由の1つは、アプリケーションドメインとユーザーがこれらの標準自体を使用しない可能性があることです。一部のドメインがいくつかの標準を使用している場合でも、それらの一部は、多くの場合歴史的な理由により、ISO標準とは異なる選択をした可能性があります。
ユーザーが既存の手順で既に「UK」を使用している場合（1） 「グレートブリテンおよび北アイルランド連合王国」を参照する場合、データ構造で「GB」を使用することは必ずしも意味がありません（特に、国によって意味するものが「ISO」の国ではない場合、たとえば分離する場合）英国の国々、またはチャネル諸島との微妙な違いなど）。もちろん、内部ストレージとプレゼンテーションの間のマッピングを行うこともできますが、場合によっては、それが少し上になることがあります。プログラミングのためにプログラミングを行うことはめったになく、多くの場合、環境に適応する必要があります。（2）
また、これらの標準はソフトウェアと並行して進化したことも覚えておく必要があります。多くの場合、他のソフトウェアのコンテキスト内で開発する必要があります。その一部は不完全に設計されている可能性があり、一部は依然としてレガシー決定の影響を受ける可能性があります。
内部データストレージ形式を確認しても、いくつかのあいまいさは解決が困難です。たとえば、私が知る限り、Excelはタイムスタンプを表すために10進数を使用します。これは、参照日付からの日数として整数を使用し、10進数の後は24時間の割合を表し、時間を表します。 ..問題は、これによりタイムゾーンまたは夏時間（1日23時間または25時間）を考慮できなくなり、Excelはデフォルトで日付/時刻をその内部形式に変換することです。 ISOフォーマットを使用するかどうかは、操作する必要のある別のソフトウェアの選択肢がない場合は関係ありません。
（1）ここで「プログラミング手順」という意味ではありません。
（2）なぜ私に質問しないでくださいpeople日常生活でもこれらの標準を使用しないでください。つまり、YYYYmmddは明確で、dd/mm/YYYYは明確ですが、mm/dd/YYYYのように中、小、大の粒度で日付を並べるのは、意味がありません:-)。
ISO 3166-1 alpha-2 国コードを使用しないのはなぜですか？
私は STANAG 1059 国コードを使用しているので、その英国では英国のコードです（ISO 3166-1によるGBではなく）。
または、 [〜＃〜] fips [〜＃〜] 国コードを使用することもできます。ここでも、英国は英国の国コードです。
多くの標準（ISOおよび非ISO）があり、特定のドメインがISO標準と互換性のない標準を使用/要求する場合があります。
20140201を保存することは明確です。 ISO規格に従っている知識を含めた場合にのみ、それが明確になります。同じことが2014年2月2日にも当てはまります。形式がmm/dd/yyyyであるという知識を含めると、完全に明確になります。
アプリケーションが他のアプリケーションとインターフェイスする必要がない限り、文書化された標準はどれでも同じように機能します。
人間にとって簡単なもの（私は1-2-2014を使用する傾向があります）とコンピュータ（ISOの代わりにバイナリ表現を使用する方がよいでしょう）の間にはトレードオフがあります。初心者プログラマーは簡単に理解できるものにこだわる傾向があり、プログラマーがコンピューター指向ストレージの利点を理解し始める経験が増えます。
私の経験では、プログラマーは以下のようなさまざまな理由でISO標準を使用できません。
- 「ISO標準があることを知りませんでした」（言われたら正当な理由ではなくなります！）
- 「標準にアクセスできません（コピーを見つけることができません/）」（本当に??）
- 「標準は制限が厳しすぎる」（通常、標準が「しない」と言っている場合は、それには十分な理由があります。それを無視して、あなたとあなたの顧客の危険を冒してください！）
- 「標準には最新の機能/ライブラリが含まれていません」（標準には、使用したいすべてのライブラリが含まれているので、標準が含まれている/カバーしているものの標準に準拠し、その標準と一致しているそれはしません）
- 「標準が実装するには面倒すぎる」（非常に使いすぎた言い訳ですが、以下を参照してください）
私がスタッフから受け入れられる唯一の理由は、不十分な言い訳ではないので、「標準は実際には適切な「適合」ではない」という証拠に裏付けられています。該当するISO規格の複雑さは、問題/解決策に比例しない場合があります。ソリューションを実装するコンテキストが、標準で想定されているコンテキストと大幅に異なる場合があります。そして時々、標準は改善することができます-それは進歩が起こる方法です。
多くの場合、ISO標準を使用できないのは、経験不足、怠惰、傲慢が原因です。私は英語を話すプログラマーが国際化に関して特に怠惰の罪を犯していること、そして私たちの米国の同僚がISOを「無関係なヨーロッパのもの」（これは当てはまらない少数派への謝罪）として認識する傾向があることを残念に思います。
これまでに指摘されていない点は、国際基準の文化的妥当性です。
測定の国際基準を検討してください。それらを米国のユーザーに紹介しましょう。米国のすべてのユーザーがキロ、キロ、リットルに満足するかどうかはわかりません。
国際基準が政府によって作成されていることを考慮してください。スペイン政府がバスク語を認識しないことを選択した場合、どのようにしてISO仕様を取得しますか？これは特に、疎外されたグループの方言やクレオールの問題です。
国コードでさえ問題になる可能性があります。クリミア自治共和国は独自の国コードを取得していますか？公式は最終的に見つかりますが（たとえば、「旧マケドニアユーゴスラビア共和国」）、外交や戦争が終結するまで、アプリケーションにいくつかの代役が必要になる場合があります。
国際標準は特定のアプリケーションを念頭に置いて作成されていると考えてください。これらはアプリケーションに完全に適合しない場合があります。たとえば、手紙を送る目的で言語を保存している場合は、たとえ米国英語など、話すのが上手でも、ブラインドを明確にコーディングしたい場合があります。統計調査組織は、人口調査中に起こりうるあらゆるEdgeケースに遭遇するため、変数（別名、変数の「メタデータ」）の正確な意味を指定する必要性をよく認識しています。その厳格さの一部は、データベースフィールドにとって非常に価値があります。
最後のポイントは、これらの種類の選択を行う際に、プログラムが政治的な声明を出す可能性があるということです。この現実は、最も優れたコードを混乱させる可能性があります（たとえば、同じ言語に対して複数の言語名が必要になる場合があります）。
ISOには多くの規格があります。 CCITT/ITUと同様。これらの標準のいくつかは「志願的な」標準であり、その他は最低限必要な機能です。どちらがどれであるかは、しばしば明確ではありません。
1980年代に、一部の機器ベンダーが標準の1つのサブセットを実装し、他のベンダーが異なるサブセットを実装する理由を尋ねたのを覚えています。そのとき、何かが機能する前に標準が設定されることがよくありました。また、ベンダーは相互運用性を妨げるために、意図的に標準を実装しないことを選択し、それによって利点が得られます。
それが、IETF RFCが好きな理由です。 RFCの3つの独立した実装があるまで、それらはRFCになることさえありません。
Oracleデータベースを構築していて、日付を格納したい場合は、OracleのDATEデータ型を使用します。 OracleがISO標準に準拠しているかどうかはわかりません。これは実際には私の別の規格（Oracle規格）への準拠の事例であり、ISO規格からそれほど逸脱しているわけではありません。 @Davidの応答を参照してください。
場合によっては、自分が設計したものにISO規格があることに気づいたときには、以前に戻って再設計するためのコストが法外であるか、少なくともそのように考えられていました。
短期的には、既存の標準を注意深く調査するよりも、利用可能な標準を使用したり、新しい標準を発明したりすることで、より多くの実用的なコードが生成されます。欠点は、大規模な統合に相互運用性が必要な場合です。これはほとんどの場合、後のプロジェクトのコンテキストで発生します。