5

Windows 上の公式の Python 2.5 は、32 ビットの time_t を使用する Visual Studio.Net 2003 でビルドされました。したがって、年が 2038 年を超えると、例外が発生します。

これは Python 2.6 (VS2008 で time_t を 64 ビットに変更) で修正されていますが、多くのモジュールが既にコンパイルされているため、2.5 を使用したいと考えています。

ここに私の質問があります-私のプログラムが2038年を超えて公式のPython 2.5をまだ使用していることを簡単に処理できるようにする解決策はありますか? たとえば"time64"、「longtime」などの事前に作成されたライブラリなど...

2.6+ にアップグレードするように言われたり、バグを忘れたりしないでください。それを機能させる必要があるのには理由があります。そのため、ここに質問を投稿します。

4

3 に答える 3

7

標準ライブラリのdatetimeモジュールは問題なく動作するはずです。time提供されてdatetimeいないモジュールから何が必要ですか?

于 2009-05-08T13:34:27.450 に答える
7

陳腐に聞こえるつもりはありませんが、それはなぜですか。

  • Python 2.5 の Y2038 バグは忘れてください
  • 2038 年より前の将来のある時点で Python 2.6 にアップグレードする

編集： 明確にするために：（そして私は真剣です—冗談を言うつもりはありませんでした）

おそらく、今から 2038 年までの無期限に Python を 2.6 (またはそれ以降) にアップグレードできます。

アプリケーションの Python タイムスタンプ変数の違いを認識している場合 (私はあまり Python ユーザーではありません)、考慮すべき重要な側面は次のとおりです。

  • 永続的に保存されているデータ
  • 永続化された Python 2.5 タイムスタンプ変数が Python 2.6 を使用して復元される方法 (おそらく「正しいことを行う」)
  • 古いデータが、あいまいさが生じるのに十分な期間、永続的な形式で保存されるかどうか (たとえば、1950 年から 2049 年の間を考えると、「96」という年は明確ですが、そのデータが 2230 年まで保持される場合、「96」は 1996 年になる可能性があります) 、2096、または 2196)

回答が好意的である場合は、通常のタイムスタンプと 2038 バグを使用してください。これを、別のタイムスタンプ (データベースのタイムスタンプ文字列など) でアプリケーションを動作させるために必要な再設計/リファクタリングの量と比較する必要があります。

于 2009-05-08T13:35:51.223 に答える
4

私が見つけた最善の解決策は、Python 2.5 のソース コピーを取得し、time_t をデフォルトで 64 ビットに設定するコンパイラ (VS2005 や VS2008 など) を使用して time モジュールを再コンパイルすることです (サイドバイを防ぐために C ランタイムを構成することもできます)。 -サイドの問題)。

于 2009-12-08T09:17:53.970 に答える