技術的雑談-log4cxx-0.9.7のTimeZoneバグ

使用OS : RedHat Enterprise Linux
log4cxx-0.9.7

現象

log4cxxをリンクしたプリケーションでlocaltime()系の関数を使うと、時刻がOS設定のTimezoneではなく、GMTになってしまう。
(日本で使っている場合は)logなどの時刻が9時間遅れる

原因

log4cxx-0.9.7での既知のバグです。

参照：http://permalink.gmane.org/gmane.comp.apache.logging.log4cxx.devel/137

log4cxx-0.9.7のtimezone.cppの中にあるlog4cxx::helpers::TimeZoneクラスの中で「TZ」という環境変数を操作していますが、TimeZoneクラスのコンストラクタを空文字列で初期化しようとしたときはTZ環境変数も空文字に設定されてしまう為、結果的にGMTとして認識されてしまいます。

参照： linux JMプロジェクト、tzset(3)より抜粋

TZ 環境変数が存在しているが、その値が空だったり、以下に示す形式のどれにも
あてはまらない場合は、協定世界時 (Coordinated Universal Time: UTC) が
用いられる。

また、TimeZoneクラスの中で、環境変数を変更したままほったらかしている。
結果、そのプロセスで以降TimeZoneがGMTになってしまう。

TimeZoneクラスは自身の中に自身のstaticなインスタンスを持っている為、liblog4cxx.soが読み込まれた時点でTimeZoneクラスのコンストラクタが呼ばれる。
なのでアプリケーションの最初からTimeZoneが狂う恐れがある。

詳細な原因は不明だが、log4cxxのSyslogAppenderでsyslogを出力させると突然TimeZoneが直ったりする。

対処

TOP ↑ ↓

上記のURLにあるパッチを適用する。

もしくは、2006/02/16現在まだリリースされていないが、log4cxx-0.9.8にupgradeする。
log4cxx-0.9.8ではTimeZoneなどの計算処理にapr(Apache portable Runtime : Apacheプロジェクトの汎用的なLibraryらしい)を使っているので、ソースを見る限りでは同じ問題は起こさないらしい。少なくともTimeZoneクラスの中では。

しかし、log4cxx-0.9.7の中ではアチコチでTZ環境変数をいじっている所があるので何か危険なにおいがする。