UNIX TIMEを用いるメリットは何でしょうか?2038年問題などの問題もあり、今の時代に敢えて使用するメリットがわかりません。昔はメリットとされたこと、今後も他の形式(文字列型、日付型など)を使用するよりもメリットとなることを教えてください。私自身が漠然と不思議に思ったことなので、どういった視点からの回答でも構いません。

回答の条件
  • 1人2回まで
  • 登録:2008/03/12 10:46:43
  • 終了:2008/03/12 20:07:52

ベストアンサー

id:b-wind No.5

b-wind回答回数3344ベストアンサー獲得回数4402008/03/12 14:20:17

ポイント40pt

現状で

  • 普及している
  • タイムゾーンによる影響を受けない
  • 実用的な精度を持っている(秒単位)
  • 取り扱いがしやすい(実質中身は整数型なので)

などの条件を満たしているのがたまたま UNIX TIME だっただけ、という気がします。

もちろん最初に出ている「普及している」は最重要項目ですが、他でダメという理由はありません。

実際 RDBMS 等で使用されている timestamp 型は実装にもよりますがミリ秒までの精度をもち、過去・未来において UNIX TIME より広い範囲を扱えるものもありますが、

処理効率や、メモリ使用量の点で通常の利用に必要かどうかは疑問です。


また、2038年問題自体は UNIX TIME 自体の問題では無いと考えています。

これを扱うための time_t 型の代表的な実装がたまたま 32bit だっただけで 64bit の実装があれば、2038年問題は発生しません。

(問題を未来に先送りするだけですが)

本質的な問題は残りますが、現実的に取りうる対処としてはベターだと思います。

id:dam-soya

ちょっと調べてみましたが、MySQLでは以下の通りなんですね。今まであまり考えずにTIMESTAMP型を使っていたので勉強になりました。

DATETIME型 1000-01-01 00:00:00~9999-12-31 23:59:59

TIMESTAMP型 1970-01-01 00:00:00~2037年の一定の時点

引用元:http://powerdee.com/it/mysql/dataTypes.html

2008/03/12 20:05:31

その他の回答(4件)

id:j1960 No.1

j1960回答回数322ベストアンサー獲得回数212008/03/12 11:09:11

ポイント40pt

メリットは他でも使っているから。

時間を扱うシステムはUNIX系のサーバーが多い。少なくとも昔はそうだった。定義も明確で間違いようが無い。

サーバー同士で共通の時間をやりとりする必要がある場合に共通の仕組みを使った方が便利なので皆UNIX TIMEを用いている。

少なくとも、今はちゃんと使えているのでここ数年のレンジで変更する必然性もなくそのまま使っている。

というのが現実だと思いますね。

日付型や文字列型はそれこそ千差万別に種類があるので元となる形式を決めないと始まらないし。

id:dam-soya

なるほど、広く使われている上に定義も明確であることが大きな理由なのですね。

日付型や文字型というだけでは、比較対象にならないですよね…もう少しいい例を考えるべきでした。

2008/03/12 11:26:36
id:watch00 No.2

watch00回答回数112ベストアンサー獲得回数02008/03/12 11:12:30

ポイント25pt

>どういった視点からの回答でも構いません。

では遠慮なく。

2038年以降は、使えなくなるので、

仕事が確実に確保できます。

http://blog.hooktail.org/?eid=410363

id:dam-soya

(笑)

UNIXTIMEを使うことで、将来の仕事を増やすわけですね

2008/03/12 11:28:59
id:pahoo No.3

pahoo回答回数5960ベストアンサー獲得回数6332008/03/12 11:17:48

ポイント30pt

UNIX TIMEと2038年問題は、直接的に結びつくものではありません。

UNIX TIMEを表現するtime_t型が32ビット型で実装されているケースが多く、そのために2038年問題が起きるわけですが、1999年に策定されたC99では64ビットの long long 型が加わり、time_t型をunsigned long long(64ビット)で定義しているCコンパイラも登場しています。こうした処理系を使えば、2038年問題は回避できます。

また、time_t型を引数とするctime関数は、「うるう秒」を補正してくれます。1972年以降、23回のうるう秒が発生していますから、長期にわたる時間計算においてはUNIX TIMEのメリットはあると思います。


参考サイト

id:dam-soya

うるう秒の存在は完全に失念していました、ありがとうございます。確かに他の日付を表す形式では、少々扱いに困りますよね(変換が複数回必要になったり、そもそも秒数までカウントしていなかったり)。

64ビットまで対応すれば私が挙げた問題も関係なくなるわけで、デメリットは使い方次第になりそうですね

2008/03/12 15:48:51
id:hujikojp No.4

hujikojp回答回数101ベストアンサー獲得回数72008/03/12 11:32:35

ポイント30pt
  • 単純な数値なので、二つの時刻の間の差が簡単に求められる
  • 逆に、1週間などを求めるのが簡単 (struct tmとかだと繰り上がりとか面倒)
  • 時差の対応も楽

永続的なデータに Unix timeを使うのがいいかはいまとなってはやや疑問が残りますが、j1960さんも書いているような冗長性の少なさはまだ魅力だと思います。

次は JavaTimeあたりでどうでしょう:

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Time.html#setTi...(long)

id:dam-soya

計算の手間は確かに少ないですよね。Java初級者の私もUNIX TIME関連の関数は少しづつ覚えながら活用しています。

JavaTimeについては、次に学習するべき知識、という意味でよろしかったですか?

2008/03/12 19:56:17
id:b-wind No.5

b-wind回答回数3344ベストアンサー獲得回数4402008/03/12 14:20:17ここでベストアンサー

ポイント40pt

現状で

  • 普及している
  • タイムゾーンによる影響を受けない
  • 実用的な精度を持っている(秒単位)
  • 取り扱いがしやすい(実質中身は整数型なので)

などの条件を満たしているのがたまたま UNIX TIME だっただけ、という気がします。

もちろん最初に出ている「普及している」は最重要項目ですが、他でダメという理由はありません。

実際 RDBMS 等で使用されている timestamp 型は実装にもよりますがミリ秒までの精度をもち、過去・未来において UNIX TIME より広い範囲を扱えるものもありますが、

処理効率や、メモリ使用量の点で通常の利用に必要かどうかは疑問です。


また、2038年問題自体は UNIX TIME 自体の問題では無いと考えています。

これを扱うための time_t 型の代表的な実装がたまたま 32bit だっただけで 64bit の実装があれば、2038年問題は発生しません。

(問題を未来に先送りするだけですが)

本質的な問題は残りますが、現実的に取りうる対処としてはベターだと思います。

id:dam-soya

ちょっと調べてみましたが、MySQLでは以下の通りなんですね。今まであまり考えずにTIMESTAMP型を使っていたので勉強になりました。

DATETIME型 1000-01-01 00:00:00~9999-12-31 23:59:59

TIMESTAMP型 1970-01-01 00:00:00~2037年の一定の時点

引用元:http://powerdee.com/it/mysql/dataTypes.html

2008/03/12 20:05:31
  • id:KuroNeko666
    仕事という意味なら、2038年問題の前に、2036年問題がありますよ。
    NTPを利用していると起きるかもしれない事象ですね。

  • id:b-wind
    >ちょっと調べてみましたが、MySQLでは以下の通りなんですね。
    ちょうどいい例かもしれない。
    その例では datetime 型で 64bit, timestamp 型で 32bit になっている。
    別例としては PostgreSQL の timestamp 型は
    範囲:4713 BC~5874897 AD、精度:1μ秒、14桁
    となっている。
    http://old.postgresql.jp/document/pg826doc/html/datatype-datetime.html
    やろうと思えばここまで出来るいい例だと思うが、ここまでの情報が
    必要な状況はまれだろう。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません