7

API では、日付を iso8601 として送信する必要があると定義されていますが、日付として「永久に」送信する必要があり、標準ではこれがカバーされていないようです。9999 年 12 月 31 日よりも優れた解決策を提案できる人はいますか? より適切な別の基準はありますか?

4

1 に答える 1

4

ISO 8601:2004(E) の引用:

3.5 拡張 情報交換におけるパートナーの相互の合意により、暦年を識別するコンポーネントを拡張することが許可されます。これは、そうでなければ 4 桁に制限されます。これにより、完全な表現でサポートされている範囲外の暦年の日付と時刻、つまり年の開始前 [0000] または年末 [9999] の参照が可能になります。

また、ISO 8601 で定義されている表現に干渉しない限り、基本的に自由に独自の表現を定義できると述べているセクション3.7 相互合意も関連する可能性があります。したがって、9999-12-32 または 9999-13-00 は提案された値について相互に合意する必要がありますforever

一般的な慣行については、場合によると思います。

可能な限り 3.7 を使用します。しかし、セットアップ全体における自分の役割を評価することが重要です。たとえば、利便性や将来の互換性のために、独自のコンポーネント セット内でサード パーティの API を使用している場合、まったく問題はないはずです。あなたがより大きなシステムの一部であり、他の何十ものシステム関係者/コンポーネント/モジュール/などを説得する必要がある場合. 苦労する価値はないと思います。

レガシーコードをチェックすることも非常に重要です。そして、少なくとも、信じられないほどセットアップが壊れた場合に備えて、移行を行う方法について計画を立ててください。それは、API の「拡張機能」を文書化することから、実際にレガシー コードの保守担当者にパッチを送信することまで、あらゆる可能性があります。

于 2012-07-10T07:59:31.623 に答える