7/1 0時(日本時間の9時)閏秒が挿入される。
通常59秒の次は00秒だが、60秒が追加される。http://www3.nhk.or.jp/news/html/20150628/k10010130831000.html
BigQueryにうるう秒が差し込また時に、きちんと動くかどうかを確認する。
bigqueryへは通常のロードの他に、td-agent経由でデータを入れることが多いので、td-agent経由でデータをインサートする場合も検証する。
結論
td-agent,bigqueryへのデータロード共に、 特に対策は必要ないようだ。
BigQueryのうるう秒対策
BigQueryが異常な動作をしないか？
うるう秒が入ることで、BigQueryが異常な挙動を示すか？
こちらの記事によるとBigQueryは、1秒を20時間にぼかして埋め込むことで、59:60秒を作らないようにしている。そのため、BigQueryが異常な動作をすることは無いだろう。
BigQueryはうるう秒(60秒)を受け入れるか？
データロードで閏秒を含むレコードを挿入してみると問題なく挿入できた。
1 2015-07-01 09:00:00.000 +09:00
2 2015-07-01 08:59:60.000 +09:00
みたいなデータをBQにロードしてみると、
1 2015-07-01 00:00:00 UTC
2 2015-07-01 00:00:00 UTC
のようにエラーなしでデータが入る(60秒は、次の00秒に置換される)。
fluentdのうるう秒対策
rubyはうるう秒を送信するか？
タイムゾーンの設定によって、rubyはうるう秒を扱うかどうかが変わる。
通常のタイムゾーンを使用しているので、rubyがうるう秒自体を送信しないだろう(単に一秒ずれる)。
他のシステムのログで、うるう秒が含まれている場合
td-agentでtailプラグインを使えば、他のアプリが吐いたログも収集できる(例えばapacheのログとか)。
例えば、あるアプリのログで、2015-07-01 08:59:60が含まれている場合、2015-07-01 09:00:00として処理される。
2015-06-29 17:27:38 +0900 [info]: plugin/in_tail.rb:475:initialize: following tail of /Users/kshibao/Prog/bq/leap_time_test/test2.csv
2015-07-01 08:59:59 +0900 debug.out: {"id":"1","uid":"11","str":"test1","str_time":"2015-07-01 08:59:59"}
2015-07-01 09:00:00 +0900 debug.out: {"id":"2","uid":"12","str":"test2","str_time":"2015-07-01 08:59:60"}
2015-07-01 09:00:00 +0900 debug.out: {"id":"3","uid":"12","str":"test3","str_time":"2015-07-01 09:00:00"}
timeを指定したものは、2015-07-01 08:59:60を渡しても、2015-07-01 09:00:00として処理される。
2015-07-01 09:00:00 +0900 debug.out: {"id":"2","uid":"12","str":"test2","str_time":"2015-07-01 08:59:60"}
ログの文字列としては、2015-07-01 08:59:60 として渡されれるが、Rubyのstrptimeを内部で使っているようで、2015-07-01 09:00:00として処理される。上のrubyの処理と同じだと考えられる。
まとめ
BigQueryも、td-agentも特に対応が必要ないようだ。タイムゾーンで、right/Japanみたいな特殊なタイムゾーンを指定している場合は、どうなるか調査できていない。