なぜ時間に8時間の差が生じるのか
Solrはデフォルトで協調世界時（UTC）を使用して時間を処理します。一方、日本や中国を含む東アジア地域では標準時としてUTC+8（中国標準時、CST）が用いられています。このため、ローカルサーバー上の日時をSolrにインデックス登録する際に、内部的にUTCへ変換する過程で8時間のオフセットが発生します。
たとえば、アプリケーション側で2018-10-10 20:00:00という日時を送信した場合、SolrはこれをUTC基準に変換し、保存時には2018-10-10T12:00:00Zとして記録されます。クエリ実行時にこの値がそのまま返されるため、「8時間遅れている」ように見える現象が発生します。
Solrのタイムゾーンを確認する方法
Solr Admin Dashboardを利用して現在のタイムゾーン設定を確認できます。
- Solr管理画面にアクセスし、左ペインの「Java Properties」を選択。
- プロパティ一覧を下部までスクロールし、「user.timezone」の値を確認。
この値がUTCまたは空の場合、デフォルトのUTCが使用されています。正しくUTC+8に設定されている場合はGMT+8またはAsia/Shanghaiなどの表記になります。
タイムゾーンの変更手順
データ同期におけるタイムゾーンの影響
SolrはData Import Handler（DIH）を通じてRDBMS（例：MySQL）やNoSQL（例：MongoDB）とのデータ同期を行います。この際、最終更新時刻を元に増分インポートを行う仕組みです。
以下の構成ファイル例では、前回のインデックス時刻を比較して新しいデータのみを取得しています。
<entity name="article_delta"
query="SELECT id, title, updated_at FROM articles
WHERE updated_at >= '${dataimporter.last_index_time}'"
pk="id">
<field column="id" name="id"/>
<field column="title" name="title"/>
<field column="updated_at" name="updated_at"/>
</entity>
ここでdataimporter.last_index_timeがUTCで保存されており、データベースのupdated_atがJST（UTC+8）で管理されていると、条件式が正しく評価されず、予期しない結果となる可能性があります。
タイムゾーン変更の必要性
データソースとインデクサ間での日時比較を正確に行うために、両者のタイムゾーンを整合させる必要があります。特にリアルタイム性が求められる検索システムでは、時刻の不一致によるデータ漏れを防ぐためにも、タイムゾーンの統一が強く推奨されます。
設定ファイルの修正方法
Linux環境におけるSolr起動スクリプトsolr.in.shを編集することで、起動時のJVMタイムゾーンを指定できます。
該当ファイルを開き：
vim $SOLR_HOME/bin/solr.in.sh
以下の行を探し、コメントアウトを解除して値を変更します：
# オリジナル（コメント済み）
# SOLR_TIMEZONE="UTC"
# 変更後
SOLR_TIMEZONE="GMT+8"
保存後、Solrサービスを再起動します：
$SOLR_HOME/bin/solr restart
再起動後、再度Solr Adminの「Java Properties」からuser.timezoneがGMT+8になっていることを確認してください。
また、より明示的なタイムゾーン名としてAsia/TokyoやAsia/Shanghaiを使用することも可能です。その場合は以下のように設定します：
SOLR_TIMEZONE="Asia/Shanghai"
これにより、夏時間（DST）の考慮も含めた正確な時刻処理が可能になります。