Unixtimeについて考えてみる
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