一般的に、プログラミングにおける日付の処理はけっこう面倒な部類の処理だと思いますが、古い日付を扱う場合はもっと面倒になるよという話をします。サンプルコードはJavaで書いていますが、他の言語でも同様の問題は起こると思います。1887-01-01T00:00+09:18:59[Asia/Tokyo]日本標準時のタイムゾーンオフセットは基本的に「+09:00」なのですが、1887年を指定すると、なんとタイムゾーンオフセットが「+09:18:59」となっています。秒も含まれていて一般的なフォーマットと違うため、たとえばこの値をサーバで生成してクライアントに返すなどした場合、フロントエンド側のJavaScriptのコードでパースした時に失敗するといった問題が起こり得ます。databaseで実際そうなっているためです。databaseとは、名前の通りタイムゾーン情報のデータベースです。JavaではJREに同梱されており、Javaで日時を扱うライブラリから参照されています。databaseにそのことが反映されているということです。ケース2:日付が10日間すっ飛ぶ旧APIとJava8以降の新APIで結果が変わるという例です。00:00:00"1582/10/4を指定し、それがそのまま出力されました。1582-10-14T00:18:59なんと、10日間もずれてしまいました。原因ライブラリによって、1582年10月15日より前の扱いが異なるためです。1582年10月15日は特別な日付で、現行のグレゴリオ暦が導入された日です。それよりも前はユリウス暦という暦が使われていました。それで、1582年10月15日より前の日を実際通りにユリウス暦として扱うライブラリと、擬似的にグレゴリオ暦(先発グレゴリオ暦)として扱うライブラリに分かれていて、Javaにおいては旧APIが前者、新APIが後者と違いがあるため、結果が変わってしまったということです。ユリウス暦からグレゴリオ暦への移行は、ユリウス暦における1582年10月4日の翌日を、グレゴリオ暦の1582年10月15日とする形で実施されました。実際に10日間すっ飛んだので、その差が日付ライブラリの処理結果としてそのまま出たわけです。1950-08-01T00:00+10:00[Asia/Tokyo]日本標準時のタイムゾーンオフセットは基本的に「+09:00」です。(2回目)しかし、この結果だと「+10:00」となっています。databaseが実際そうなっているからです。時事ネタですが、少し前に東京オリンピックのためにサマータイムを導入しようと騒がれていたことがありますよね。その時にニュースなどを見て知っている方も多いかもしれませんが、日本でも1949年〜1951年頃、実際にサマータイムが導入されていました。databaseに反映されているわけです。upLoginユーザーは見つかりませんでした。