以前、時間に関するスニペットを言語別に7パターンぐらい書いたのだが、あまりその中では触れなかったが、timeの値を扱う時、保存する時、どういうフォーマットが望ましいかを検討してみました。
考えられるフォーマット
YYYY-MM-DD
inputタグのtype="date"でPOSTすると、「-」ハイフンで年月日を区切られた１０バイトの文字列になる。
区切り文字があるので、月と日が、１桁の数値になっても対応できるし判別もし易いかも。
そして、「-」ハイフンを「/」スラッシュに変換しても、テキストデータに保存した時に、日付っぽく判断しやすくなる。
2017-12-1
YYYYMMDD
上記の区切り文字が無いバージョンで、８バイト固定で扱える。
容量が一番エコである。もちろん、２０００年問題の教訓を捨てると、YYMMDDという扱いでもいいかもしれないが、ここは好き嫌いが分かれそうなポイントだ。
20171201
YYMMDD
上記に書いたのでとりあえず、この型も入れておく。
月と日を必ず２桁にしなければいけないので、実際に使う時に数値型にすると文字型にするときにsprintfなどの処理が必要になる。
６バイトとかなりエコである。
171201
unix-time
1970年１月１日0時0分0秒からスタートした秒数で現される値。
ちなみに2017年12月1日は「1512086400」で２０２０年12月1日は「1606780800」という値のようだ。
次回桁が増えるのは、2286年11月21日の予定なので、２世紀半ぐらい先の世界である。
考えなくてもいいだろう・・・
ちなみに、2000年1月1日は「946684800」という値なので、この数値を引いてあげると非常にコンパクトな数値を扱える事になる。
１年間で増加する値は、60秒×60分×２４時間×365日=31536000・・・１０進数で8文字分使う事になる。そう考えると、YYYYMMDDと同じ容量と考えてもいいが、あとはどちらが計算が早く出来るかという点かも。
1512086400
Json形式
連想配列で持つことができるので、順番などを任意で入れ替えることも可能になる。
ただし、年月日は時分秒と全てセットで、連動して値が繰り上がる必要があるので、分ける必要があるかどうかは、扱い方次第。
そして、バイト数は、１日分で27バイトから29バイトぐらい必要になる。
{"Y":"2017","M":"12","D":"1"}
アルゴリズム検討
実際にプログラムで利用する時は、日次の取得から、「○年○月○日」という表示フォーマットへの変換や、「○日後」という処理で、ある日数からn日後の日次を取得する事が想定できる。
その時に扱いやすいフォーマットは、「unix-time」だ。
秒数で持っておくと、n日後はかなり簡単に計算できる。
逆に１ヶ月後、１年後という単位は、ymd形式で持っていると扱いやすい。
これらの事を総合的に判断すると、容量の点からみても、データはUnixTimeで保持し、ymd形式に自由に変換しながら、一番最適で速度の早い方法でコードを書くのが、扱いやすいし、エコでもあるという事。
そもそも、データ保存は、SQLにまかせていて、時刻計算もselect文だけで行なっているエンジニアがいるとしたら、今回の記事は何も参考にならないかもしれないが、優秀でスピードが早いプログラマーは、上記のような関数をすでに自分用として持っている人が多いだろう。
また、PHPなどは、便利関数の塊言語なので、とにかく軽い値を保持できれば、あとはいかようにでもなる。
あとは、エンジニアとしてのどれがいいかという決めだけである。
JSON形式で、{"date":"20171201"}と考えた人、僕の思考に近いかもしれない・・・
以前のリンク
[言語別TIME処理] Javascriptで時間処理
[言語別TIME処理] PHPで時間処理
[言語別TIME処理] Pythonで時間処理
[言語別TIME処理] Shellで時間処理
[言語別TIME処理] C言語で時間処理
[言語別TIME処理] Go言語で時間処理
[言語別TIME処理] Ruby時間処理
