おすすめライフログ LIFELOG(@osusume_life)の
かずのりです。

フリーランス15年以上の現役エンジニアです。

現在、コロナの影響で自宅で作業中の
ノマドワーカーです。

まず、グリニッジ時刻についてまとめた訳ですが、私が実際の現場でこのようなことを言われました。

「データ検索の件数が違うのはグリニッジが影響があるのでは？」

グリニッジ？

私がグリニッジといえばグリニッジ時間。

それが検索結果に影響がある？

なぜそのようなことを言うのか？

私は一瞬いろいろと考えました。

「ひょっとしたらAWSサーバはグリニッジ時刻で動いているのか？」

などなど、イマイチその方が言っているグリニッジが何を指しているのか不明でしたのでグリニッジについてまとめてみました。

グリニッジとは？

グリニッジとはグリニッジ標準時といわれ、かつては国際的な標準時刻に採用された基準時刻

グリニッジ標準時、グリニッジ平均時/Greenwich Mean Time (略：GMT）

イギリスのグリニッジ天文台から発行された航海暦から火が付きイギリスの航海士が次々に時間を合わせるようになりそれが世界で標準時刻として扱われるようになった

データベースとグリニッチ標準時について

データベースには時間を扱う型があります。
TIMESTAMPデータ型

このTIMESTAMPデータ型ではGMTを採用しています。

実際のデータベースでは日本人にわかりやすいJTCで表示されていますが実際のデータはGMTで格納されています。

データベースはSELECT文を実行された場合、設定されているタイムゾーンを確認し、JTCで表示させるかどうかを内部で計算しています。

なので、本題の「グリニッジの影響で件数がずれたのでは？」を理解すると「データベースはグリニッジ標準時なので日本時間のJTCに変換しないと正確な時間が出ないのでは？」ということがわかります。

AWSサーバーとグリニッジ標準時について

AWSサーバーはグリニッジ標準時で動いています。
そのため設定画面の時刻をみても日本時間ではないので９時間のズレが発生しています。

よくクーロンを設定するときに時間になっても動かない！ってことがある場合は、グリニッジ標準時を疑ってみても良いと思います。

余談ですがデータベースのTIMESTAMPデータ型には問題が・・・

余談なのですがデータベースのTIMESTAMPデータ型にはなんと

「2038-01-19 03:14:07」

までしか時刻は設定できません。

これを「2038年問題」と言われてます。

そもそもTIMESTAMPデータ型の時刻の設定範囲は「1970-01-01 00:00:01」から始まり「2038-01-19 03:14:07」まです。

理由はコンピューターはもともとUNIX時間を採用しており1秒ごとデータを加算していきます。

UNIX時刻はC言語で書かれており1秒毎加算していくと2038年で32ビットが最大値になるそうです。

回避策はあるものの古いマシンだと2038年までしか動かないという噂がながれていますが、みなさんのmacなどはエポック秒を採用しているのでこの問題は関係ないです。安心しましたか？

まとめ

時間については歴史的な背景もあり今思えば「え？」って思うかもしれませんが歴史をたどっていくと「そうだったのか？」と思います。

また、各国ではそれぞれのタイムゾーンがありますし、日本のタイムゾーンは日本標準時JSTとよばれており、「東経135度の子午線の時」をもって日本における一般の標準時と定められています。

時間に関してはまだまだ説明しきれないほどたくさんの呼び方などがありますが今回はこの辺りとさせていただきます。

ここまで読んでいただきありがとうございます。

他の記事もありますのでぜひ、読んで行ってください。

今後ともヨロシクお願いします