こんにちは。

毎年気の利いた嘘の一つでもつきたいと思いつつ、エイプリルフールをスルーしている岡安です。

クラウドを使いこなすために、最低限の知識をご紹介するシリーズ第2弾。

今回は、「日付型データ」についてです。

前回の「クラウドを使いこなすための基礎の基礎:文字コードってなんなの?」に引き続き、クラウドにデータをアップロードしたり、ダウンロードする際に悪さをすることのある「日付型データ」について、簡単にまとめてみました。

データのアップやダウンロードができた~♪と思ったら、
・日付のはずが「42461」と謎の数値に変換されてしまった
・数字の「1」を入れたはずが「1900/1/1 0:00:00」のデータになっている
なんていうことを防ぐために必要な知識ですので、ご参考まで。

 

詳しく知る必要がない人向けの最低限押さえておくべきポイント

ほんとに必要なことだけ押さえておきたいという人は、とりあえず、

・日付型データは、元データ(例えばExcel)内の形式とアップロード先の形式があっていないと、正しいデータが投入できないことが多い
・「日付(2016/04/04)」のデータと「日付+時刻(2016/04/04 00:00:00)」は異なる形式と認識される
・日付型データ⇔テキストデータの変換を行う場合は注意が必要
・Excelのファイルを直接アップすると日付データがうまく投入できない場合には、CSV形式に変換するとうまくいくことがある

を覚えておけばOKです。

とりあえずなんかうまくいかないなと思ったら、いったんCSVにしてみましょう。

CSVで保存されているデータを確認し、アップロード先の形式と合致していれば、ほとんどの場合うまくいくはずです。(ダウンロードしたデータがおかしい場合は、CSVでダウンロードして、Excelではなく、テキストエディタで確認してみるとよいかもしれません)

 

日付型データとは

詳しく知りたい方向けにもう少し解説を続けます。

システム上で管理されている顧客データや日誌データなどを使用する場合、例えば「今月」のデータだけ見たいとか、「前年同月比」のデータと比較して見たいといった要望が当然ながら出てきますよね?

こういった使い方をするために、日付型のデータが必要になってくるのです。

どういうことかというと、今月(例えば2016年4月)のデータを見たい場合、システムで登録されているデータから、必要なデータ(今月のデータ)だけを表示させる必要があります。

つまり今月のデータを表示させるためには、
・2016年3月31日以前のデータ
・2016年5月1日以降のデータ
を排除する必要があるわけです。

ほかにも、特定のお客さんの最新購入日付を表示させたい、とか、購入して30日後にアンケートを送るなどといったさまざまな場面で、日付の大小を比較したり、日付を足したり引いたりなど、「計算させる」必要性が出てきます。

ただし、この日付ってやつは単純な数字と違って、
・月によって日数(28~31まで)が違う
・曜日も毎年一定ではない
・4年に一度だけ現れるレアキャラがいたりする
・時間も含めると、年・月・日・時間・分・秒など異なる単位が混在している
など少し特殊なデータなのです。

そのため、単純な数字とは違った管理や計算を行う必要があり、その計算や管理を正しく行うために定められているのが、「日付型データ」ということになっています。

 

なぜ日付型データで問題が起こるの?

では、なぜ日付型データが問題を引き起こすことがあるのでしょうか。

これにはいろいろな複合的な要因が絡んできます。

思いつくままに挙げるだけでも、
・地域によって、表示形式が異なる(日本:2016/4/1、アメリカ:4/1/2016)
・データをわける記号が複数ある(例:2016/4/1、2016-4-1)
・データをわける記号が計算で使われる記号だったりする(例:/(スラッシュ)は割り算、-(ハイフン)は引き算)
・西暦を2桁で表示(2016年は16とか)したり、月を単語(Springとか)で表現することもある
・日本独自の和暦がある
・内部で管理されている数字と実際に表示されている形式は異なる(例:Excel内のシリアル値と表示形式)
・システムによって、データ型の扱いが異なることがある
とわんさか出てきます。

少し具体的に書いてみると、クラウドに日付型データをアップするような場合、Excelでの日付型のデータの扱い方で影響が出ることが多いですね。

Excel内では、日付型データは、実際には日付そのものではなく「シリアル値」という値で内部的に管理され、それを様々な書式(2016/04/04とか2016年4月4日とか)に変換して表示する、という管理方法をとっています。

Excel上では、正しく2016/04/01と表示されていたとしても、クラウド側が表示形式まで正しく読み取ることができないと、数字と判断されて、謎の数値(シリアル値)が表示されたりアップされたりして、なんじゃこりゃ?となるのです。

ちなみにこのシリアル値は、「1900/1/1 0:00:00」を「1」として、日付を整数(つまり「1900/1/2 0:00:00」は「2」)として扱っています。

そして、日付未満の時間などについては、1日が86,400秒ですので、1日分である整数「1」を「86,400」で割った数値を1秒として計算するという複雑な形で管理されています。

シリアル値などは詳しく知る必要はありませんので、そういうもんなんだと聞き流しておいてください。

 

日付型データで問題を起こさないために何をすればいいの?

これは先ほど挙げた通り、さまざまな原因がありますので、一概には言えませんが、以下のような対策が考えられます。

・変わった形式の日付は扱わない(西暦の上2桁を省略するとか。2000年問題の原因ですね)
・特に必要でなければ時間・分・秒までは扱わない方が無難(データ更新日など自動で入るものはあえて変える必要はありません)
・Excelのデータは、いったんCSVにしてアップする(見えない内部管理データを介在させないようにする)

日付データがなぜかうまくアップされないような場合の参考としていただければ幸いです。

ではでは。