📌

Unixtimeについて考えてみる

2020/11/15に公開

1. 概要

システムに携わっている人なら、Unixtimeについて一度は目にしたことがあると思います。初めて見たときは何だこの数値と感じるとは思いますが、慣れてしまうとどうってことなくて、むしろUnixtimeで管理することが合理的と感じます。ただ、なんとなくUnixtimeを使っているだけだと、なんでUnixtime使ってるんだっけとなるので、今回は改めてUnixtimeについて考えを記しておきたいと思います。

2. Unixtimeとは

Unix timeの記事から抜粋すると、Unixtimeはこのような意味を表す数字となります。

  • 元期1970年1月1日0時0分0秒 (UTC) (Unix epoch、The Epoch) から経過した秒単位の時間を数として表したものです。
  • どこのどんな地方時 (標準時、サマータイム) を使っていて、それが UTC どどれだけの時差があるのであっても、 その時差情報は Unix time に含めることはできません。Unix time はどの瞬間であるかだけを表します。

3. 日付型と比較した時のUnixtimeのメリット・デメリット

私的に感じるメリット・デメリットは以下の通りです。なお、日付型を使用した時に留意すべきことは後述します。

【メリット】

  • Unixtimeで処理を行う限りは、タイムゾーンを考慮する必要がない。
  • APIで別のシステム(モジュール)にデータを連携する時、日付のフォーマットを考慮する必要がない。
  • 数値型なので日付の計算処理が楽。

【デメリット】

  • テーブルのデータから、これがいつの日付を指すか認識しにくい。
  • 非エンジニアにとって、これが日付の意味であることを認識しにくい。
  • 型情報から日付であることを類推できない。

4. 日付型での処理時の留意点

【プログラムでの取り扱い】

Date And Time APIの日時クラスの記事はJavaの例ですが、プログラムにおいてどのように日付を扱うかは留意が必要です。例えばタイムゾーンをUTC固定で扱うか、オフセットは付けるか・付けないか、サーバの日付設定に依存させるかどうか。ここら辺をきちんとルール化しておかないと、バグが発生する原因になると私は考えています。

【DBでの取り扱い】

DBにおいても日付型が存在します。MySQL 8.0.19 のオフセットつき日時リテラルはMySQLの記事です。MySQLでは、DATETIME型とTIMESTAMP型が存在していて、それぞれ仕様が異なります。ここでもオフセットの有無はどうするか、タイムゾーンは何で保存するかというルール決めをきちんとする必要があります。

5. 所感など

システムにおいて日付型をきちんと扱うのは、意外に大変と私は思います。もちろん、メンバー間で日付型の運用が認識を取れていれば問題ないのですが、新しくきたメンバーなどに周知されていない場合、バグ等が発生する原因となります。内部処理で扱う分にはUnixtimeがシンプルで、バグやメンバー間の認識齟齬も発生しにくくなると考えてます。
一方で、Unixtimeだとシステムの表側で使うことがためらわれます。日付型で扱ったほうが良いという場面も出てくると思います。
結論としては適材適所で使い分けるのがベターというふうになるのですが、なぜ日付型にしているのか・Unixtimeにしているのか、という説明がきちんと出来ることが大事な気がします。

Discussion