3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

で、結局UTC、GMT、Unixtimeって何が違ってどう書けばいいの???

Posted at

事の発端

お仕事で時刻の変換の処理を書いたのですが、今までなんとなく「new Date()」の関数でやり過ごしてきてしまっていました。今回は「サマータイムの処理も頑張って書いてね。」と言われて色々調べたのでその結果を備忘として残したいと思います。
(かなり基礎的な情報なので、初心者向けです。)

時間表現の違い

(UT、)UTC、GMT、Unixtimeとは何かについて書いていきます。

UT(Universal time)

天文観測に基づきイギリスのグリニッジを通る本初子午線に対する平均太陽時角に12時を加えたもので表される世界共通の時間。
あまり実務で意識することはないかもしれません。

GMT(Greenwich mean time)

英国のグリニッジ(経度0度)の地方平均時(平均太陽が南中する時を正午とする)のことで、一般的な意味合いではUTと同義語。
こちらはnew Date()をするタイミングで見たことがあるかもしれませんね。

UTC(Coordinated universal time)

まず、UTCを理解する前段階として、原子時計と国際原子時の説明をします。

原子時計

セシウム原子の振動数を基準にした時系で、1年に百万分の1秒ほども狂わない高精度な時計です。

国際原子時

基準時計として最も安定した原子時計が採用され、1958年1月1日0時0分0秒の世界時を原点としてスタートしたのがです。
ところが、地球の自転速度にふらつきがあるので、この原子時計を基準にすると秒の単位が常に変動してしまい、様々な問題が発生することがわかりました。

協定世界時:Coordinated universal time

ここで登場するのがUTC(協定世界時:Coordinated universal time)です。
世界協定時とは、国際原子時と世界時の誤差が0.9秒以上ならないようにうるう秒で調整をした時間で、原子時の精度を保ちながら、太陽の運行と時間の表示がさほど狂わないように調整したものらしいです。

Unixtime

各々のPC端末内に持っている時間で、協定世界時 (UTC) での1970年1月1日午前0時0分0秒から形式的な経過秒数(すなわち、実質的な経過秒数から、その間に挿入された閏秒を引き、削除された閏秒を加えたもの)
PCは時々サーバに時刻(UTC時刻)を取得しに行ってこのUnixtimeを調整することで、時間がずれないようにしているらしいです。
Unixtimeは経過時刻なので、現在は10桁の数字で表されています。
例えば、日本時間での13:58:06秒は 1580360290 のような形で表されます。

参考
CITIZEN公式サイト
Wiki

実装の話

では具体的にJSではどう書けばどんな時間が取れるの?というところを書いていきます。

実行環境
  • Chromeのコンソール
  • タイムゾーン:Tokyo

new Date()

new Date()
Thu Jan 30 2020 14:01:47 GMT+0900 (日本標準時)

new Date()をした時は使っている端末のタイムゾーンでの現在時刻が取得できます。

new Date().toISOString()

new Date().toISOString()
2020-01-30T05:28:18.076Z

使っている端末のタイムゾーンでの時刻(東京の時刻)を世界標準時に直した時刻が取得できます。

new Date().getTimezoneOffset()

new Date().getTimezoneOffset()
-540

取得したDateと世界標準時の誤差を取得できます。
東京は9時間進んでいるので、-(9 * 60)分の誤差が返って来ていますね。

Date.now()

Date.now()
1580360742505

Date.now()をした時は使っている端末のタイムゾーンでの1970年1月1日午前0時0分0秒からの経過秒数を取得できます。

だいたいこんなところでしょうか?

サマータイムはどうする?

私の仕事上の課題は、自システムにサマータイムを導入するためにどうするか、ではなく、欧米圏はサマータイムやっているけどその時Dateモジュールの動きが変わるのでは???という懸念から生まれたものでした。
結論として、UTCもUnixtimeも基準となる地点からの経過時刻なので、それがサマータイムという制度によって変わるわけではないから、特別なロジックは必要ないね。と落ち着きました。

自サービスがサマータイムの制度上で動く場合は時間がズレる月にズラすロジックが必要になるのだと思います。

まとめ

  • UTC
    原子時の精度を保ちつつ、地球の自転とのズレを吸収して運用されている世界共通時刻
  • GMT
    英国のグリニッジ(経度0度)の地方平均時(平均太陽が南中する時を正午とする)
  • Unixtime
      各々のPCに持っている時間で、UTCを基準としてタイムゾーンを反映した時間

読んでくださってありがとうございました。
認識違いなどありましたら教えてくださると嬉しいです!

3
4
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
3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?