0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PerlAdvent Calendar 2024

Day 21

Time::Piece の時間範囲の罠について

Posted at

こちらは Perl Advent Calendar 2024 の21日目の記事になります。

今年はなかなか書くネタが見つからなかったので、
時間に関するちょっとした小ネタを紹介します。


昨年、MySQL 8.0移行に際して、以下の記事を書きました。

昔のテーブルに 0000-00-00 が入っている問題

MySQL 8.0から、DATETIME型のZERO_DATEの扱いが更に厳格になりました。
(5.7ではWARNINGのみだったものが、エラーになってしまう。 sql_mode で変えることも出来ますが、できるだけ標準に合わせておきたい)

大昔に作成されたテーブルには、 0000-00-00 の値が結構入っていたので、
DATETIME型の最小値である 1000-01-01 に更新することでひとまず対応しました。

この時の対応で、後ほど一点問題が見つかったのでせっかくなので紹介させていただきます。

ZERO_DATEの対応として、0000-00-00 -> 1000-01-01 に一括で変更していて、
概ねうまくいっていたのですが、ある箇所で以下のような500エラーが発生していることが後になって判明しました。

undef error - Error parsing time at /usr/local/perl-5.38/lib/5.38.2/x86_64-linux/Time/Piece.pm line 598.

エラーの箇所を追ってみると、以下のstrptime呼び出しの箇所で発生しているようでした。

Time::Piece では 1000-01-01 の日付には対応していなかったようです。

$ perl -MTime::Piece -E "say Time::Piece->strptime('1001-01-01', '%Y-%m-%d')"
Error parsing time at /usr/local/perl-5.38/lib/5.38.2/x86_64-linux/Time/Piece.pm line 598.

$ perl -MTime::Piece -E "say Time::Piece->strptime('1899-12-31', '%Y-%m-%d')"
Error parsing time at /usr/local/perl-5.38/lib/5.38.2/x86_64-linux/Time/Piece.pm line 598.

$ perl -MTime::Piece -E "say Time::Piece->strptime('1900-01-01', '%Y-%m-%d')"
Mon Jan  1 00:00:00 1900

MySQLのDATETIME型の最小値としては 1000-01-01 ですが、
Time::Pieceの最小値は 1900-01-01 となっていたという問題でした。

これまで日付の範囲についてさほど意識したことがなかったため、
なんなくPerlの内部ではUNIXエポックの1970年が境目で、Time::Pieceもそのあたりなのかと考えていた程度でした。

この時は 1900-01-01 にするか、もしくは 1970-01-01 にするかで悩んだのですが、
どちらもDB側のカラムを見ただけだとPerlの時間の扱い由来であることがすぐにわかりにくいかと思い、2000-01-01 にすることで暫定対応を行いました。(これも微妙ですが。。)

さきほどのstrptimeのパース箇所は

の方で定義されているようで、自分はXS側に詳しくないので解説は省略させていただきますが、おそらくCのライブラリ側で制限されていそうでした。
日付の範囲について日頃あまり意識してなかったので、今回ちょっとだけ試してみました。

時間系モジュールの取りうる範囲

32bit時代であれば、例の2038年問題が該当してくるかと思います。

$ perl -MTime::Local -e 'print "Min: ", scalar localtime(-2**31), \
"\nMax: ", scalar localtime(2**31-1), "\n";'
Min: Sat Dec 14 05:45:52 1901
Max: Tue Jan 19 12:14:07 2038

が、さすがに今どきは64bit環境になっているとおもうので、64bit環境のみとします。

Time::Piece

$ perl -MTime::Piece -E "say Time::Piece->strptime('1899-12-31', '%Y-%m-%d')"
Error parsing time at /System/Library/Perl/5.34/darwin-thread-multi-2level/Time/Piece.pm line 598.
$ perl -MTime::Piece -E "say Time::Piece->strptime('1900-01-01', '%Y-%m-%d')"
Mon Jan  1 00:00:00 1900
$ perl -MTime::Piece -E "say Time::Piece->strptime('9999-12-31', '%Y-%m-%d')"
Fri Dec 31 00:00:00 9999
$ perl -MTime::Piece -E "say Time::Piece->strptime('10000-12-31', '%Y-%m-%d')"
Error parsing time at /usr/local/perl-5.38/lib/5.38.2/x86_64-linux/Time/Piece.pm line 598.

1900-01-01 - 9999-12-31 のようでした。

DateTime

$ perl -MDateTime -E "say DateTime->new(year => -9999999999999999, month => 1, day => 1)"
-9999999999999999-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => -9999, month => 1, day => 1)"
-9999-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 0, month => 1, day => 1)"
0000-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 1, month => 1, day => 1)"
0001-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 1001, month => 1, day => 1)"
1001-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 9999, month => 1, day => 1)"
9999-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 10000, month => 1, day => 1)"
10000-01-01T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 1000000000000000, month => 12, day => 31)"
1000000000000000-12-31T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 10000000000000000, month => 12, day => 31)"
-2626367463883276--02-4611686018427387893T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 10000000000000000000, month => 12, day => 31)"
-12330607835522389-10-22T00:00:00
$ perl -MDateTime -E "say DateTime->new(year => 100000000000000000000, month => 12, day => 31)"
-0001-12-31T00:00:00

オーバーフローはしてしまうものの、特に下限、上限の範囲は設定されていないようでした。

まとめ

もともとMySQL 8.0以前からのZERO_DATEのようなカラムがあったとして、それを意味のある数字に変更する際には、Perlにおいては、取り急ぎ1900年より前の値は使わないようにしておいた方が無難そう。
それよりは、NULLを許容するように定義を変えたり、アプリケーション側でDATETIME型だけど実体を持たない場合に適当なデフォルト値を入れないで済むような組み方に変えていった方が良いと思いました。

MySQL DATE/DATETIME型の範囲は '1000-01-01' から '9999-12-31' ですが、そのままアプリケーションからも扱えるとは思わない方が良さそうです。
2038年問題周りは64bit時代でもまだ予期せぬ問題がありそうなので、また時間を取って調査してみたいです。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?