プログラマーがISO標準を無視するのはなぜですか？[閉まっている]

私がよく遭遇することの1つは、ISO標準に準拠していないプログラムによって引き起こされる問題です。

1つの例は、ISO国テーブルを使用せず、独自の短縮形を作成することです。これは、米国（米国）またはオランダ（NL）には問題ありませんが、英国（GBではなく英国）またはスペインには見事に間違っています。 （ESではなく、SP）および他の多くの国。

別の例として、内部日付表記。なぜ誰もが日付を2014年1月2日として保存するのでしょうか？それが2月1日であるか1月2日であるかは完全に不明ですが、ISO標準を使用する場合は2014-02-01 *のみを保存し、2月1日であることは明白です。

私の質問：ISO規格が利用可能な場合、プログラマーはいつ、なぜ独自の構成を作成する必要がありますか？

_{* 2014-02-01を保存し、エンドユーザーに表示するときに日付を適宜フォーマットします。}

愚かさによって十分に説明されている悪意に起因することはありません。- ロバートJハンロン。

それと、コミュニケーション不足。

だから、それは反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デザインを行う際には、HTMLが古代バージョンのHTMLの制限されたサブセットよりも機能豊富であるため、ISO HTML（HTML 4.01 Strictの小さなサブセット）よりもHTML5を使用することを非常に好みます。

したがって、ISO標準を無視するのには十分な理由があります。

あなたの例では、「GB」は英国の国コードです。ただし、「UK」はかつてMARC（米国議会図書館）の標準コードでしたが、これは非推奨だと思います。そして、IANAは.uk英国のトップレベルドメインに使用します。

したがって、何かがISO標準に準拠していない場合、標準が使用されていないという意味ではありません。それは単に異なることを意味するかもしれません標準が使用されます。（@Jörgがコメントで指摘したように、標準の良いところは、選択できるものが非常に多いことです。）その場合、問題は実際にどの標準が特定の問題ドメイン、環境などに最も適切になるかです。

その質問への回答は、おそらく大部分が意見に基づいており、すぐに「宗教的な」議論に退化するでしょう。しかし、ISO標準への準拠が常に最良の答えとは限りません。たとえば、あるソフトウェアがライブラリデータベースと連動する必要がある場合、ISOよりもMARC標準の方が適切な選択になる可能性があります。組織のソフトウェアの大部分が特定の方法で機能している場合、少なくとも短期的にはそのアプローチに固執することをお勧めします。結局のところ、それは組織の「標準」です。

また、標準は進化/変更します。昨日適合したものは今日ではないかもしれません。

そして、私はあなたが指摘する問題の原因として無知やナマケモノを排除したくないでしょう...開発者は単にそれらに対処するのに十分な時間を持っていなかったかもしれません。

ISO規格への準拠は、必ずしも費用のかからない活動ではありません。使用しているツールキットに特定の標準がまだ実装されていない場合、プログラマーは必要な選択に直面します。今すぐこれを適切に実装するか、標準を実装せずに後で変換を処理する方が安価ですか？

「ほら、いつも標準を実装すべきだ」と言うのは簡単ですが、すべてにコストがかかります。また、プログラマーがISO標準の実装を望まない理由はいくつかあります。

• 顧客は、独自規格または非ISO規格に従っている場合があります。顧客が望むものやあなたの言語が必要とするものに加えて、追加の実装を隠すことで、後継者に意図しない頭痛を残すよりも、顧客が期待している標準に従うことをお勧めします。
• 大量の既存データが存在する可能性があり、変換またはフォーマットブレークがまだ実行できない場合があります。現地の日付時刻をキーとする20年の顧客連絡先と契約がある場合、正しく実行できるまで、これらの何億ものフィールドすべてをISO標準日付に変更する必要は必ずしもありません。
• 標準を順守すると、利益が提供するよりも大きなコストがかかる場合があります。たとえば、完全に米国内でエントリを処理している場合、5文字のISO-3166-2コード（US-NY）は、標準の米国郵便コード（NY）よりも不要な3文字です。

経験の浅いプログラマー/データベースデザイナーの場合、それは知らないためです。業界にまたがる人々のグループを知らないため、車輪を再発明する傾向があり、すでに問題について議論し、参加したすべての人によって承認された標準を思い付きました。しばしば非常に長い議論、改訂などの後です。ある週が1年の最後の週と見なされるか、来年の最初の週と見なされるかに関するISO標準があると彼に言ったとき、私のものは信じられませんでした（ISO 8601）。彼は、それほど具体的なものに関して標準が存在するとは考えていませんでした。私は彼に、多くのアプリケーションの正確性はその標準に依存していると言いました。

経験豊富なプログラマー/データベースデザイナーの場合、「もっとよく知っている」、ここで発明されていない症候群、および/または壮大さに起因する無視です。ISOコードは「十分に安定していない」と考えているため、ISOや他の標準機関を信頼していません。そこで、独自の、ここで作成された、または自動インクリメントされたコード/識別子を作成して相互運用性を妨げますが、これも無視します。この類似の質問をご覧ください。次のような理由があります。

標準がどれほど安定しているかに関係なく、データベース設計を多数のサードパーティ（IATA、ISO）に依存させるとは限りません。または、特定の標準にまったく依存したくない場合があります。

奇妙なことに、標準を無視する人は標準のUSBポートを使用し、標準サイズのDVDとBluRayを購入し、標準に準拠したタイヤで車を運転します。

まあ、人々はISO標準を無視する傾向があります：たとえば、あなたは書いた

ISO標準を使用する場合、20140201 *を保存するだけで、2月1日が明確になります。

しかし、完全にISO8601準拠のレンディションは実際には2014-02-01です。（xkcd 1179も参照）

理由の1つは、アプリケーションドメインとユーザーがこれらの標準を自分で使用しない可能性があることです。一部のドメインがいくつかの標準を使用している場合でも、多くの場合、歴史的な理由により、それらの一部はISO標準とは異なる選択を行っている可能性があります。

ユーザーが既存の手順^（1）で既に「UK」を使用して「英国および北アイルランド連合王国」を参照している場合、データ構造で「GB」を使用することは必ずしも意味がありません（特に、国別の意味は「ISO」の国ではありません。たとえば、英国の分離やチャネル諸島との微妙な違いなど）。もちろん、内部ストレージとプレゼンテーションをマッピングすることもできますが、場合によっては少し上になります。プログラミングのためにプログラミングを行うことはめったになく、環境に適応する必要があります。^（2）

また、これらの標準はソフトウェアと並行して進化したことを覚えておく必要があります。多くの場合、ソフトウェアの他の部分のコンテキスト内で開発する必要があります。その一部は不完全に設計されている場合があり、一部は依然としてレガシーの決定の影響を受ける可能性があります。

内部データストレージ形式を見ても、あいまいさを解決するのは困難です。たとえば、私が知る限り、Excelはタイムスタンプを表すために10進数を使用します。基準日からの日数として整数を使用し、小数点以下は24時間の端数を表し、時間を表します。 ..問題は、これによりタイムゾーンまたは夏時間（1日の23hまたは25h）を考慮することができず、Excelがデフォルトで日付/時刻をその内部形式に変換することです。ISO形式を使用するかどうかは、使用する必要がある別のソフトウェアが選択の余地がない場合は無関係になります。

_{（1）ここで「プログラミング手順」を意味するものではありません。}

_{（2）なぜ人々が日常生活でもこれらの基準を使用しないのか、私に聞かないでください。つまり、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年1月2日にも当てはまります。形式がmm / dd / yyyyであるという知識を含めると、完全に明確になります。

アプリケーションが他のアプリケーションとのインターフェースを必要としない限り、十分に文書化された標準は同様に機能します。

人間にとって簡単なもの（私は2014年1月2日から2日まで使用する傾向があります）とコンピューター（ISOの代わりにバイナリー表現を使用したほうがよいでしょう）の間にはトレードオフがあります。初心者のプログラマーは、簡単に理解できるものにこだわる傾向があり、プログラマーがコンピューター指向ストレージの利点を理解し始める経験が増えています。

これまで提起されなかった点は、国際標準の文化的適切性です。

測定の国際標準を検討してください。それらを米国のユーザーに紹介しましょう。すべての米国ユーザーがキロメートル、キロ、リットルについて満足しているとは思いません。

国際基準は政府によって書かれていることを考慮してください。スペイン政府がバスク語を認識しないことを選択した場合、ISO仕様はどのように取得されますか？これは特に、疎外されたグループの方言とクレオールに関する問題です。

国コードでさえ問題になる可能性があります。クリミア自治共和国は現在、独自の国コードを取得していますか？公式は最終的に発見されます（たとえば、「マケドニア旧ユーゴスラビア共和国」）が、外交または戦争が終わるまで、アプリケーションに代わるものが必要になる場合があります。

特定のアプリケーションを念頭に置いて国際標準が作成されていることを考慮してください。これらはアプリケーションに完全に適合しない場合があります。たとえば、文字を送信する目的で言語を保存している場合、たとえばアメリカ英語などの会話に堪能であっても、視覚障害者を明確にコーディングすることができます。統計機関は、人口調査中にあらゆる可能性のあるエッジケースに遭遇するため、変数の正確な意味（別名変数の「メタデータ」）を指定する必要性をよく認識しています。その厳密さの一部は、データベースフィールドにとって価値があります。

最後のポイントは、これらの種類の選択を行う際に、あなたのプログラムが政治的声明を発表している可能性があることです。この現実は、最高のコードを混乱させる可能性があります（たとえば、同じ言語に対して複数の言語名が必要になる場合があります）。

私の経験では、プログラマーは次のようなさまざまな理由でISO標準を使用できません。

• 「ISO標準があることを知りませんでした」（あなたに言われたら、正当な理由ではなくなります！）
• 「標準にアクセスできません（コピーが見つかりません/コピーできません）」（本当に??）
• 「標準は制限が強すぎる」（通常、標準に「禁止」と書かれている場合には、正当な理由があります。あなたとあなたの顧客の危険を無視してください！）
• 「この標準には最新の機能/ライブラリが含まれていません」そうではないこと）
• 「この標準は実装するのが面倒です」（過度に使い古された言い訳ですが、下記参照）

私がスタッフから受け入れた唯一の理由は、口実が悪い言い訳ではないとして、「標準は本当に良い「適合」ではない」-証拠に裏付けられている。該当するISO規格の複雑さは、問題/解決策とは比例していない場合があります。ソリューションを実装するコンテキストが、標準で想定されているコンテキストと大幅に異なる場合があります。そして、時には標準を改善することができます-それが進歩が起こる方法です。

しかし、多くの場合、ISO標準の使用の失敗は、経験不足、怠laz、or慢に起因する可能性があります。英語を話すプログラマーは、国際化に関して特に怠で有罪であり、米国の同僚はISOを「無関係なヨーロッパのもの」（これが当てはまらない少数派への謝罪）と見なす傾向にあることを後悔しています。

ISOには多くの標準があります。CCITT / ITUと同様。これらの標準の一部は「熱心な」標準であり、その他は最低限必要な機能です。どちらがどれであるかは明確ではありません。

1980年代に、一部の機器ベンダーが標準の1つのサブセットを実装し、他のベンダーが別のサブセットを実装する理由を尋ねたのを覚えています。そのとき、何かが機能する前に標準がしばしば設定されることが明らかになりました。また、ベンダーはしばしば、相互運用性を妨げることができるように、意図的に標準を実装しないことを選択します。

IETF RFCが好きなのはそのためです。RFCの3つの独立した実装があるまで、それらはRFCにさえなりません。

Oracleデータベースを構築していて、日付を保存したい場合は、Oracle DATEデータ型を使用します。OracleがISO標準に準拠しているかどうかは知りませんし、気にしません。これは、実際には別の標準（Oracleの標準）に準拠している場合であり、ISO標準からそれほど離れていません。@Davidの応答を参照してください。

場合によっては、自分が設計したもののISO標準が存在することに気づいたときには、元に戻って再設計するコストが法外なものであったか、少なくともそのように見えました。

短期的には、既存の標準を注意深く研究するよりも、利用可能な標準を使用するか、新しい標準を発明することにより、より多くの実用的なコードが生成されます。欠点は、大規模な統合に相互運用性が必要な場合に発生します。ほとんどの場合、これは後のプロジェクトのコンテキストで発生します。