SSH経由で大学Linuxサーバー（RHEL 7）に接続しています。私の問題は "ls"と "old"ファイルに関連しています。
メインディレクトリ：
$ touch -d '1918-11-11 11:00 GMT' wwi-armistice
$ touch now
$ sleep 1
$ touch now1
$ TZ=UTC0 ls -lt --full-time wwi-armistice now now1
-rw-r--r-- 1 tsai csugrad 0 2054-12-17 17:28:16.000000000 +0000 wwi-armistice
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 22:07:10.743637000 +0000 now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 22:06:59.992632000 +0000 now
一時ディレクトリ：
$ tmp=$(mktemp -d)
$ cd $tmp
$ touch -d '1918-11-11 11:00 GMT' wwi-armistice
$ touch now
$ sleep 1
$ touch now1
$ TZ=UTC0 ls -lt --full-time wwi-armistice now now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 23:04:27.031485854 +0000 now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 23:04:22.907373125 +0000 now
-rw-r--r-- 1 tsai csugrad 0 1918-11-11 11:00:00.000000000 +0000 wwi-armistice
私は、2054年の世界大戦休戦の理由がUnix時間の符号付き32ビットから符号なし32ビットへの変換に関連していることを示す最初の出力を知っています。誰かがこれを確認し、その理由（ネットワーク関連？）を説明できれば良いでしょう。
2番目の大きな質問は：/ tmpで例を実行すると、なぜwwi-armisticeが正しくリストされているのですか？
答え1
実行中のオペレーティングシステムでは、動作の違いの根本的な原因を特定できません。ファイルアクセスおよび変更時間を保存するために使用されるファイルシステムも同様に重要です。
推測できるように、無効な2054-12-17日付は、ターゲット日付が符号なし32ビット整数として記録されたが、符号付き32ビット整数として読み取られたためです。
1918-11-11 11:00:00=154193400032ビット最小符号なし時間1901-12-13 08:45:52以降の秒（）2054-12-17 17:28:16=154193400032ビット最大署名時間以降の秒（2038-01-19 03:14:16）
ホームディレクトリは、NFSv3またはこれらの日付を32ビットで保存するローカルファイルシステムに保存できます。
一方、64ビットで日付を保存するすべてのファイルシステムでサポートされているため、/tmpこの問題の影響を受けません。tmpfsext4