time_t

#include <time.h>

定義は後述。

C++では、std::time_tである。

#include <ctime>

namespace std {

typedef 処理系依存 time_t;

}

定義は後述。

_tで終わる型は大抵はシステムデータ型で、必ずどこかでtypedefされている。元がどのような型であるかは、実装に委ねられている。

従来の実装では32ビット符号付き整数型(signed long int)だが、これは2038年問題を起こす。

32ビットのままでも無符号(unsigned long int)にすれば2106(令和88)年2月7日まで簡単に問題回避が可能だが、Cの日時処理の関数mktime()関数などはエラー時に(time_t)(-1)を返すという仕様があったため、64ビット化しsigned long longを採用することとなった。

このように、signed longではなくtime_tとしていたのは、サイズが変わった時にも対応できるようにした保険の一つだった。

ちなみに、POSIX(IEEE Std 1003.1-2004)仕様では、time_tは整数でも浮動小数点数でも良いとされている。しかしdoubleやlong doubleでは秒単位が正確に表現できない可能性が高く、浮動小数点数で実装しているシステムは現時点では確認できていない。

各ビットごとの最大日時は次の通り。

• 31ビット 2038/01/19 03:14:07
• 32ビット 2106/02/07 06:28:15
• 33ビット 2242/03/16 12:56:31
• 34ビット 2514/05/30 01:53:03
• 35ビット 3058/10/26 03:46:07
• 36ビット 4147/08/20 07:32:15
• 37ビット 6325/04/08 15:04:31
• 38ビット 10680/07/14 06:09:03

(中略)

• 52ビット 142715360/12/06 03:48:15
• 53ビット 285428751/11/12 07:36:31
• 54ビット 570855533/09/22 15:13:03
• 55ビット 1141709097/06/13 06:26:07

Ubuntu 10.04のgcc 4.4.3とFreeBSDのclang/LLVMで確認したところ、正しいかどうかは不明だがフルビットでは55ビット(0x7fffffffffffff)までは一応動作した。

しかしそれ以上は想定外の問題として、struct tm内のint tm_yearがオーバーフローしてマイナスになってしまい、正常動作しなくなるもよう。要するに、年が31ビットに収まらないといけないということである。

したがって、2147485548/12/31 23:59:59までしか扱えないということになる。このときのtime_tは、0xf0c29d868bfd7fである。つまり21億4748万5548年問題があることになる。

なお、オーバーフロー時、gcc 4.4.3はデタラメな結果を返すが、clang/LLVMは1900/01/00 00:00:00を返す。つまりstruct tmの中をゼロクリアして返却する。

Windows用のC/C++コンパイラーであるVisual C++ 2010(Microsoft C/C++ Version 16)の場合、gmtime()関数で扱えるtime_t値の上限は、0x7934126cfだった。

これは、3001/1/1 20:59:59(UTC)に対応する。つまり、3001年問題が存在することになる。

古いVC++に限らず、古い処理系は概ね同じ。

• typedef long time_t;

Microsoft Visual C++ 2003環境では、次のように定義される。

• typedef _W64 long time_t; (Win32)
• typedef __int64 time_t; (Win64)

つまりWin32環境では31ビット長、Win64環境では63ビット長である(有効桁数が1ビット足りないのは符号があるため)。

_W64は、Visual C++ 32bitの場合__w64キーワードに展開される。これは、/Wp64を指定した時に、64ビット対応の型であると指定するものである。

Microsoft Visual C++ 2005/2008環境でも同様であるが、若干定義が異なる。

• (crtdefs.h) typedef __int64 __time64_t;
• (crtdefs.h) typedef __time64_t time_t;

Win32環境でも__int64は利用可能で、もってtime_tは64ビット化されている。

time.hなど

typedef __time_t time_t;

stddef.h → sys/_types.h → machine/_types.h と間接的に呼ばれた /usr/include/machine/_types.h で、次のように定義される。

typedef int __int32_t;

typedef long __int64_t;

(32ビットFreeBSDの場合)

typedef __int32_t __time_t;

(64ビットFreeBSDの場合)

typedef __int64_t __time_t;

FreeBSDでは、間接的にintまたはlongで定義される。もって64ビット版ではtime_tは64ビット化されている。

Javaは、Cのtime_t互換の仕様は導入せず、独自のjava.util.Dateクラスを用いて日時を管理する。

従って2038年問題など、Cに存在する問題は生じない。