日付-1901年より前の年は無効として扱われます

11

私のシステムには日付（GNU coreutils）7.1がインストールされています。

1901年12月14日より前の日付を確認しようとすると、「無効な日付」エラーが発生します。例えば、

  $ date -d 1901-12-13
  date: invalid date `1901-12-13'

  $ date -d 1901-12-14
  Sat Dec 14 00:00:00 EST 1901

dateユーティリティで1901年より前の年を有効として扱うにはどうすればよいですか？

2038年1月19日以降の日付でも同様のエラーが発生する

shell-script date

— ジャスディープ・シン
ソース

エラーは発生しません。coreutils 8.10を使用していますが、古いバグでしょうか？

— xenoterracide

@xenoterracideは64ビットシステムですか？

— ミケル

@Mikelはい、私は

— ゼノテラサイド

15

良い質問。

ドキュメントは、それが許されるべきであると言います。

 info date 'Date input formats' 'Calendar date items'

数値の月の場合、ISO 8601形式の「YEAR-MONTH-DAY」が許可されます。ここで、YEARは任意の正の数です...

数値が10未満の場合は、先行ゼロが必要です。

YEARが68以下の場合、2000が追加されます。それ以外の場合、YEARが100未満の場合は、1900が追加されます。

32ビットシステムを使用していますか？

2038-01-20以降の日付でもエラーが発生しますか？

date -d '2038-01-20'

もしそうなら、それはGNU日付が32ビットの時間値を使用しているように聞こえます。

64ビットシステムを使用したり、別のツール（PerlのDateTimeやPythonのdatetimeなど）を使用したりする以外に、どうすればこれを修正できるかわかりません。

背景：

Unix時間は、整数値を使用して1970年1月1日からの秒数をカウントします。システムが32ビット整数を使用している場合、前方に21億秒（最大2038-01-19 03:14:02 UTC）および後方に21億秒（1901-12-13 20:45:52に戻る）しかカウントできません。 UTC）。

詳細については：

— ミケル
ソース

Mikelに感謝します。32ビットマシンを使用していると思います。実際、私はリモートサーバーで作業しており、サーバーはunameコマンドを使用しても多くの情報を公開しません。2038年問題に関しては、そうです、その問題はリモートサーバーに影響がないことです。ご入力いただきありがとうございます。大変感謝いたします！！

— Jasdeep Singh

はい、i686は32ビットです。お役に立ててうれしいです。それより古い日付を処理するのにサポートが必要な場合は、私が提案したPythonおよびPerlモジュールを試してみて、機能しない場合は別の質問を投稿してください。

— ミケル

7

システム（または少なくともそのバージョンのdate）は、おそらく32ビットの内部時刻値を使用しています。

Unixエポック（ゼロの時間値）は1970-01-01 00:00:00 UTCです。この開始点は1901-12-13 00:00 ESTを符号付き32ビット時刻値の範囲のすぐ外に置きます。

1901-12-14 00:00:00 ESTは-2147454000
1901-12-13 15:45:52 ESTは-2147483648（別名INT_MINC、最小の32ビット符号付き整数）
1901-12-13 00:00： 00 ESTは-2147540400

1901-12-13 15:45:52 ESTを使用してみてください。それは動作するはずですが、1秒前はおそらく1901-12-13 00:00と同じように失敗します。

— クリス・ジョンセン
ソース