Y2Kの直後に、”next up,Y2038!”しかし、当時、それは将来的に永遠を感じ、他の誰かの問題になる可能性がありました。 今、私たちは途中であり、Y2038の問題がソフトウェア障害を引き起こす可能性がある点にすでに達しているので、Y2038の計画を開始する良い機会です。 たとえば、ソフトウェアはすでに20年の証明書の寿命や20年の住宅ローンで作業する問題を抱えている可能性があり、これらの問題の頻度はY2038に近づく Akamaiでは、すでにY2038の戦略的にターゲットを絞った内部計画とテストを実施しており、この重要な取り組みが緊急性を増しているため、この作業の範囲は今後19年間にわたって拡大し続ける可能性が高いと思われます。

January1,2000ではほとんど間違っていませんでした（現在の日付として”19100″を表示するAkamaiマーケティングサイトのJavascriptの短い！1）行われた高度な準備の量：しかし、逃した取得する一つのことは、その夜の限られたグローバルな影響は、二つの要因によるものであったということで; 2）多くの”Y2K問題”は、ロールオーバー自体の間ではなく、実際には数年前に発生しました。 うるう秒は、テストするのが難しく、事前に起こる影響がはるかに少ないという点で、日付形式の問題よりもいくつかの点で恐ろしいものです。 Y2Kの影響の欠如は、組織や技術者がY2038の準備を不十分にする可能性があるというリスクがあります。 また、y2Kよりも「Y2038」を一般の人に説明するのが難しく、高度な作業の優先順位付けと集中が難しくなる可能性があります。 私たちの環境では、多数の組み込みモノのインターネット（IoT）デバイスがユビキタスになっているため、Y2038のリスクと潜在的な影響は、Y2Kの場合よりもかなり高くなっています。

Y2038計画での私たちの最初の経験（最初の音で19年先に提起されている懸念を聞いたときに人々からのショックを見ることに加えて）は、この段階で漸進的で焦点を当てたアプローチが必要であるということです。 はるかに複雑で包括的なプログラムは確かに道の下の年のいくつかの数が必要になります。 この最初の段階では、焦点を当てるべきある区域は下記のものを含んでいます:1)未来の時間および日付を取扱うソフトウェア;2)ワイヤーメッセージおよ; 3）長い展開された寿命、およびその依存関係を持つデバイス。 もちろん、私たちが近づくにつれて、Y2038移行を安全に処理できるようにするなど、より広範なシステムセットに焦点を当てることが重要になります。

将来の日付を扱うソフトウェア

おそらく、最初に焦点を当てるべき最も重要な領域は、X.509証明書の処理や財務計画など、将来の日付を扱うソフ 多くの日付と時刻の形式表現がありますが、そのすべてにY2038の問題があるわけではありません。 たとえば、過去数世紀（1970年以前）の時間を処理する必要があるソフトウェアは、多くの場合、異なる日付と時刻の表現を選択しました。 しかし、X.509証明書（HTTPSに使用されるなど）や認証局（Ca）のケースをテストする際に、Y2038を過ぎて証明書とCaの有効期限が切れると、ラボで多数のソフトウェアの問題が発生することがわかりました。特にOpenSSLには複数の時間形式があり、ASN1_UTCTIMEにはY2049に制限があります（y2038から計画する明確な問題）ので、ASN1_TIME関数を使用すると、すべての時間範囲との OpenSSL outなどのライブラリからタイムアウトを32ビットtime_tに変換することは、問題が発生する可能性のある追加の領域です。

これらのケースの多くでは、64ビットアーキテクチャ用のレガシーソフトウェアを移植してコンパイルするだけで問題を解決することができました（例：32ビット整数time_tから64ビットtime_tに移動する）。 他のケースでは、特に時間が数学のために整数にキャストされたり、メッセージワイヤ形式が関与したり、値がデータベースに格納されたりするときに、より大規模な変更が必要とされています。 20年間のCaのサポートをテストして修正する際に現れたことの一つは、下流の依存関係も機能することです。 たとえば、20年後の日付がロギングシステムまたは監視システムに供給され、それらが警告システムまたはレポートデータベースまたはプロビジョニン

on-the-wireメッセージとファイル形式

前述のように、32ビットのタイムスタンプがメッセージ、データベース、またはファイル形式に入れられると、その影響は特定のシステムをはるかに超えて拡大する可能性があります。 これらは外部依存関係を持つシステムでもあり、相互作用がシステムの境界を越えているため、より高度な計画が必要になることがよくあります。 これらの相互運用システムのコレクションでは、変更を特定の順序でリリースする必要があり、下位互換性が頻繁に発揮されます。 さらに、メッセージに32ビットのエポック-タイムスタンプ値を使用する形式的または非公式に標準化されたプロトコルがある場合、移行または修正は標準の修正に基づいて行われる可能性があります。 そのため、次のような依存関係チェーンと同様に、これらは心配することが重要になります:

1. post-Y2038タイムスタンプをサポートするようにプロトコル/標準を更新します。
2. ソフトウェアライブラリで更新された標準のサポートを実装します。
3. ソフトウェアパッケージに組み込まれたライブラリの新しいバージョンを取得します。
4. 新しい出荷製品に含まれるソフトウェアパッケージを取得します。

これらのそれぞれが数年かかり、出荷製品の寿命が長い場合、ここでの長いリードタイムはすでに問題になる可能性があります。

長い展開寿命を持つデバイス、およびその依存関係

早期に焦点を当て始めるもう一つの領域は、長い展開寿命を持つデバイスです。 前述したように、これらのデバイスが持っている外部依存関係に従うことも重要です。 32ビットハードウェアを搭載した組み込みデバイスには、ソフトウェアの更新を介して”64ビットtime_t用にコンパイルするだけ”という簡単な修正がないか、許容できないパフォーマンスへの影響がある可能性があります。

接続された自動車やその他のIoTデバイスは、おそらく特定の懸念の領域ですが、私はデバイスやアプリケーションの他の多くの同様のタイプがあ 例えば、現在の傾向を考えると、今日販売されている車の10％以上がY2038でまだ稼働している可能性が高く、車両年齢と道路上の車両数の増加に伴い、これはさらに高くなる可能性があります。 一般的にY2038に準拠している自動車を出荷するために数年かかる場合は、自動車の年齢の現在の（そして増加する）分布で、我々は十九年で深刻な問題を持 この同じパターンは、20年以上のCA証明書がプリインストールされている家電（家庭用ゲーム機やスマートテレビなど）など、他の業界にも存在する可能性があ

展開された寿命が長いデバイスでは、y2038移行ポイントの前、中、後にオペレーティングシステムとソフトウェアが正常に動作し続けることをテス

新年あけましておめでとうございます！

Y2038の問題はIpv6と同様のカテゴリにあります。

: 一般的なケースでは重要であるが、まだ緊急ではないのは数十年の展開である（アイゼンハワー-マトリックスによると）。 この観点から、緊急（または遅すぎる）になる前に、計画、トリアージ、およびテストを開始するのと同じくらい良い時間です。 最初に、将来の日付、オンザワイヤーメッセージとファイル形式、および展開された寿命が長いデバイスを扱うソフトウェアに焦点を当てます。 次に、今後数年間で、より包括的なプログラムを構築するために、最初の焦点からの経験を使用しています。 それにもかかわらず、最小のバーを設定し、構築および展開している新しいソフトウェア、システム、プロトコル、および製品がY2038の問題を導入しないこ

Erik Nygrenは、Akamaiのプラットフォームエンジニアリング組織のフェローでチーフアーキテクトです。 彼は今年6月にAkamaiで20周年を迎えます。この記事への貢献について、Akamaiの複数の人々に感謝します。

この文書の作成には注意が払われていますが、Akamai Technologies,Inc. ここに記載されている情報の使用に起因するエラー、省略、または損害について一切の責任を負いません。 ここに記載されている情報は、予告なしに変更されることがあります。 AkamaiおよびAkamai waveのロゴは、米国における登録商標またはサービスマークです。 米国特許第6,000,000号 &Tm。 オフ）。 2019年1月10日発売。