[23] [DFN[[RUBY[Unix][ユニックス]] [RUBY[time][タイム]]]] は、 
[[Unix]] 系システムを中心に多くの[[計算機システム]]で用いられている[[日時の内部表現形式][日時データ型]] ([[整数時刻系]]) です。
[[計算機システム]]用の[[時刻系]]としては最も著名なものです。

[79] 
現在では[[キリスト紀元]] ([[西暦年]]) や[[グレゴリオ暦]]を遥かに凌ぐ、
世界で最もよく用いられている[[日時形式]]と考えられます。

* Unix time

[25] [[Unix time]] は、[[時刻]]の表現の方法の1つです。 [[Unix epoch]]
から経過した[[秒]]単位の[[時間]]を[[数]]として表したものです。

[124] 
[[Unix time]] には安定した呼称がなく、
ほかに
[DFN[POSIX time]],
[CODE[time_t]],
[DFN[epoch秒]],
[DFN[epoch time]],
[DFN[epoch]],
[[Unix epoch]]
などとも呼ばれます。

[131] 
通常は[[秒]]を[[単位]]とした[[数値]]ですが、 [N[10[SUP[n]]]] 倍した[[ミリ秒Unix time]]
や[[ナノ秒Unix time]]があります。


* 元期 Unix epoch

[109] [[Unix time]] の[[元期]]
([DFN[Unix epoch]]、[DFN[The Epoch]])
は、
[TIME[西暦1970年1月1日0時0分0秒 (UTC)][unix:0]] 
です。

[134] 
[[UTC]] のかわりに [[TAI]] を採用したものについては [[TAI64]] を参照。

* データ型

[95] いわゆる [[Unix time]] は、いろいろな方法で表現されます。表現方法によって、
記述可能な[[値域]] (最古の[[日時]]から最大の[[日時]]までの[[範囲]])
や粒度 ([[秒]]、[[ミリ秒]]等の時間的解像度)
が変わります。
具体的には言語・プロトコルの章を参照。

** 32ビット整数

[153] 
伝統的には[[32ビット整数]]の[[秒]]数が採用されてきました。

** 64ビット整数

[147] 
[TIME[令和20(2038)年][2038]]に迫った[[西暦2038年問題]]への対策として、
[[64ビット符号''付き''整数]]の[[秒]]数を採用することが多いです。

[146] 
[[64ビット符号''無し''整数]]の[[秒]]数が採用されることがあります。
[SRC[>>145]]


** 負

[7] [[負]]の値 ([TIME[西暦1969年][1969]]以前) は、環境や文脈によっては扱えないことがあります。
最近は多くの環境が[[負]]の値も扱えるようになっているようです。

** 秒未満

[37] [CODE[time_t]] は[[整数]]とするのが普通ですが、
それ以外では拡張して[[秒未満]]も含めた[DFN[小数のUnix time]]
を使うことがよくあります。

[93] 
[[精度]]・記述能力は、実際にその [[Unix time]] の値を表現する[[データ型]]や構文に依存します。

[EG[

[94] 
例えば[[浮動小数点数]]を使う場合は、その[[データ型]]で記述可能な桁数までを表現できます。

]EG]


** 値域の比較

[165] [[整数型]]による主要な [[Unix time]] の利用形態の[[値域]]は次の通りです。

- [155] [[32ビット符号付き整数]] [[秒]]単位
-- 最小値 : [CODE[1901-12-13T20:45:52Z]] [TIME[1901-12-13T20:45:52Z]]
-- 最大値 : [CODE[2038-01-19T03:14:07Z]] [TIME[2038-01-19T03:14:07Z]]
- [156] [[32ビット符号無し整数]] [[秒]]単位
-- 最小値 : [CODE[1970-01-01T00:00:00Z]] [TIME[1970-01-01T00:00:00Z]]
-- 最大値 : [CODE[2106-02-07T06:28:15Z]] [TIME[2106-02-07T06:28:15Z]]
- [158] [[64ビット符号付き整数]] [[秒]]単位
-- 最小値 : [CODE[−292277022657-01-27T08:29:52Z]] [TIME[−292277022657-01-27T08:29:52Z]]
-- 最大値 : [CODE[+292277026596-12-04T15:30:07Z]] [TIME[292277026596-12-04T15:30:07Z]]
- [162] [[64ビット符号無し整数]] [[秒]]単位
-- 最小値 : [CODE[+000000001970-01-01T00:00:00Z]] [TIME[1970-01-01T00:00:00Z]]
-- 最大値 : [CODE[+584554051223-11-09T07:00:15Z]] [TIME[584554051223-11-09T07:00:15Z]]
- [163] [[64ビット符号付き整数]] [[ミリ秒]]単位
-- 最小値 : [CODE[-292275055-05-16T16:47:04.192Z]] [TIME[-292275055-05-16T16:47:04.192Z]]
-- 最大値 : [CODE[+292278994-08-17T07:12:55.807Z]] [TIME[292278994-08-17T07:12:55.807Z]]
- [164] [[64ビット符号付き整数]] [[ナノ秒]]単位
-- 最小値 : [CODE[1677-09-21T00:12:43.145224192Z]] [TIME[1677-09-21T00:12:43.145224192Z]]
-- 最大値 : [CODE[2262-04-11T23:47:16.854775807Z]] [TIME[2262-04-11T23:47:16.854775807Z]]


[166] 
[[Web]] 上の解説等はよくみると微妙に値が違っていることもあって注意が必要です。
「何秒以後は桁溢れ (オーバーフロー) する」のような書き方だと最大値より1秒先になることにも要注意です。
[[ナノ秒]]単位の境界値は特に乱れが多いようです。
[[応用]]依存の独自の制約が加わっているらしいものもあれば、
理由がわからずただの誤記らしきものも見られます。

[169] 
正確を期すため [[ChatGPT]] に[[ミリ秒]]単位と[[ナノ秒]]単位の[[64ビット符号付き整数]]の最大値と最小値を求めるプログラムを書かせましたので、
ここに置いておきます。 [SRC[>>167, >>168]]

[REFS[

[FIG(quote)[ [167] 
>
[PRE[
docker run --rm python:3 sh -c 'python3 - <<EOF
def civil_from_days(z):
    z += 719468
    era = z // 146097
    doe = z - era * 146097
    yoe = (doe - doe//1460 + doe//36524 - doe//146096) // 365
    y = yoe + era * 400
    doy = doe - (365*yoe + yoe//4 - yoe//100)
    mp = (5*doy + 2)//153
    d = doy - (153*mp + 2)//5 + 1
    m = mp + 3 if mp < 10 else mp - 9
    y += 1 if m <= 2 else 0
    return y, m, d

def ns_to_datetime(ns):
    sec = ns // 1_000_000_000
    nsec = ns - sec * 1_000_000_000
    if nsec < 0:
        sec -= 1
        nsec += 1_000_000_000
    days = sec // 86400
    sod = sec - days * 86400
    if sod < 0:
        days -= 1
        sod += 86400
    y,m,d = civil_from_days(days)
    h = sod // 3600
    m2 = (sod % 3600) // 60
    s = sod % 60
    return f"{y:+d}-{m:02d}-{d:02d} {h:02d}:{m2:02d}:{s:02d}.{nsec:09d} UTC"

MIN = -(1<<63)
MAX = (1<<63) - 1

print("min:", ns_to_datetime(MIN))
print("max:", ns_to_datetime(MAX))
EOF'
]PRE]
]FIG]

[FIG(quote)[ [168] 
>
[PRE[
docker run --rm python:3 sh -c 'python3 - <<EOF
def civil_from_days(z):
    z += 719468
    era = z // 146097
    doe = z - era * 146097
    yoe = (doe - doe//1460 + doe//36524 - doe//146096) // 365
    y = yoe + era * 400
    doy = doe - (365*yoe + yoe//4 - yoe//100)
    mp = (5*doy + 2)//153
    d = doy - (153*mp + 2)//5 + 1
    m = mp + 3 if mp < 10 else mp - 9
    y += 1 if m <= 2 else 0
    return y, m, d

def ms_to_datetime(ms):
    sec = ms // 1000
    msec = ms - sec * 1000
    if msec < 0:
        sec -= 1
        msec += 1000
    days = sec // 86400
    sod = sec - days * 86400
    if sod < 0:
        days -= 1
        sod += 86400
    y,m,d = civil_from_days(days)
    h = sod // 3600
    mi = (sod % 3600) // 60
    s = sod % 60
    return f"{y:+d}-{m:02d}-{d:02d} {h:02d}:{mi:02d}:{s:02d}.{msec:03d} UTC"

MIN = -(1<<63)
MAX = (1<<63) - 1

print("min:", ms_to_datetime(MIN))
print("max:", ms_to_datetime(MAX))
EOF'
]PRE]
]FIG]

]REFS]

[170] 
[[浮動小数点数]]を使うと非常に広い範囲の[[時刻]]を扱えますが、
[N[0]] から余りに離れすぎると[[数]]の[[刻みの粒度][ULP]]が広がり、
[[秒]]の精度が正確に記述できなくなります。
そこで[[秒]]や[[ミリ秒]]が正確に記述できる範囲を求めると、次のようになります。


- [171] [[倍精度浮動小数点]] ([[double]] = 64ビット) [[秒]]単位で正確に表現
-- [172] 最小値 : [CODE[-285424812-02-20T16:23:28Z]] [TIME[-285424812-02-20T16:23:28Z]]
-- [173] 最大値 : [CODE[+285428751-11-12T07:36:32Z]] [TIME[+285428751-11-12T07:36:32Z]]
- [174] [[倍精度浮動小数点]] ([[double]] = 64ビット) [[ミリ秒]]単位で正確に表現
-- [175] 最小値 : [CODE[-283457-03-21T15:00:59.008Z]] [TIME[-283457-03-21T15:00:59.008Z]] 
-- [176] 最大値 : [CODE[+287396-10-12T08:59:00.992Z]] [TIME[+287396-10-12T08:59:00.992Z]]


[177] 
正確を期すため [[ChatGPT]] にこれらを求めるプログラムを書かせましたので、
ここに置いておきます。 [SRC[>>178, >>179]]


[REFS[

[FIG(quote)[ [178] 
>
[PRE[
docker run --rm python:3 sh -c 'python3 - <<EOF
def civil_from_days(z):
    z += 719468
    era = z // 146097
    doe = z - era * 146097
    yoe = (doe - doe//1460 + doe//36524 - doe//146096) // 365
    y = yoe + era * 400
    doy = doe - (365*yoe + yoe//4 - yoe//100)
    mp = (5*doy + 2)//153
    d = doy - (153*mp + 2)//5 + 1
    m = mp + 3 if mp < 10 else mp - 9
    y += 1 if m <= 2 else 0
    return y,m,d

def sec_to_dt(sec):
    days = sec // 86400
    sod = sec - days*86400
    if sod < 0:
        days -= 1
        sod += 86400
    y,m,d = civil_from_days(days)
    h = sod//3600
    mi = (sod%3600)//60
    s = sod%60
    return f"{y:+d}-{m:02d}-{d:02d} {h:02d}:{mi:02d}:{s:02d} UTC"

MIN = -(1<<53)
MAX = (1<<53)

print("min:", sec_to_dt(MIN))
print("max:", sec_to_dt(MAX))
EOF'
]PRE]
]FIG]

[FIG(quote)[ [179] 
>
[PRE[
docker run --rm python:3 sh -c 'python3 - <<EOF
def civil_from_days(z):
    z += 719468
    era = z // 146097
    doe = z - era * 146097
    yoe = (doe - doe//1460 + doe//36524 - doe//146096) // 365
    y = yoe + era * 400
    doy = doe - (365*yoe + yoe//4 - yoe//100)
    mp = (5*doy + 2)//153
    d = doy - (153*mp + 2)//5 + 1
    m = mp + 3 if mp < 10 else mp - 9
    y += 1 if m <= 2 else 0
    return y,m,d

def ms_to_dt(ms):
    sec = ms // 1000
    msec = ms - sec*1000
    if msec < 0:
        sec -= 1
        msec += 1000
    days = sec // 86400
    sod = sec - days*86400
    if sod < 0:
        days -= 1
        sod += 86400
    y,m,d = civil_from_days(days)
    h = sod//3600
    mi = (sod%3600)//60
    s = sod%60
    return f"{y:+d}-{m:02d}-{d:02d} {h:02d}:{mi:02d}:{s:02d}.{msec:03d} UTC"

MIN = -(1<<53)
MAX = (1<<53)

print("min:", ms_to_dt(MIN))
print("max:", ms_to_dt(MAX))
EOF'
]PRE]
]FIG]

]REFS]

[180] 
[[double]] は[[マイクロ秒]]単位まで耐えられますが、
[[ナノ秒]]単位となるとまったく実用的ではなくなります。
[[NTFSの日時形式]]と同等の 100ns 単位ですら、
[TIME[西暦1941年][1941]]から[TIME[西暦1998年][1998]]までしか扱えません。
[[ChatGPT]] にプログラムを書かせて検証したものを示します [SRC[>>181]]。

[REFS[

[FIG(quote)[ [181] 
>
[PRE[
docker run --rm python:3 sh -c 'python3 - <<EOF
def civil_from_days(z):
    z += 719468
    era = z // 146097
    doe = z - era * 146097
    yoe = (doe - doe//1460 + doe//36524 - doe//146096) // 365
    y = yoe + era * 400
    doy = doe - (365*yoe + yoe//4 - yoe//100)
    mp = (5*doy + 2)//153
    d = doy - (153*mp + 2)//5 + 1
    m = mp + 3 if mp < 10 else mp - 9
    y += 1 if m <= 2 else 0
    return y,m,d

def sec_to_dt(sec):
    days = sec // 86400
    sod = sec - days*86400
    if sod < 0:
        days -= 1
        sod += 86400
    y,m,d = civil_from_days(days)
    h = sod//3600
    mi = (sod%3600)//60
    s = sod%60
    return f"{y:+d}-{m:02d}-{d:02d} {h:02d}:{mi:02d}:{s:02d} UTC"

MAX_SEC = (1<<53) / 1e7
MIN_SEC = -MAX_SEC

print("min:", sec_to_dt(int(MIN_SEC)))
print("max:", sec_to_dt(int(MAX_SEC)))
print("exact limit seconds:", MAX_SEC)
EOF'
min: +1941-06-17 00:01:15 UTC
max: +1998-07-17 23:58:45 UTC
exact limit seconds: 900719925.4740992
]PRE]
]FIG]

]REFS]


** 特殊値

[88] 
[[Unix time]] には様々な場面で使われていますが、使われる場面によっては、
[[日時]]を表す以外の値が割り当てられることがあります。

[72] [CODE[mktime]] や [CODE[time][time()]] は算出不能時に値 [N[-1]]
を返します。

[70] [TIME[西暦1970年][year:1970]]を扱う必要がない場合に、値 [N[0]]
が「[[日時]]指定なし」など特別な意味を割り当てられることがあります。

[89] 
当然のことながら、こうした特殊な値を使う場面と、
これらを使わずに[N[0]]や負数を[[日時]]の表現として使う場面とで、
取扱いを誤ると混乱が生じます。


* Unix time 日時系

** 秒

[99] 
[[Unix time]] の[[秒]]は、 [[UTC]] の[[秒]]と考えられています。

;; [103] [[先発UTC]]も参照。


** 閏秒

[15] 
[[Unix time]] では[[閏秒]]は考えません。
[SEE[ [[閏秒のない時刻系]] ]]

[67] 
[[POSIX]] は1[[日]]の[[秒]]数を固定長としつつ、
実際の[[時刻]]との対応は[[未定義]]、[[実装定義]]とし
[SRC[>>10]]、[[閏秒]]の処置は曖昧にしています。
[[実装]]は [[leap smear]] などにより[[閏秒]]が存在しないものとして扱っています。

;; [38] [CODE[tm]] は[[閏秒]]を表現できることになっていますが、
[[Unix time]] で表現できないため有名無実となっています。

[69] [CODE[right/]] のような [[Unix]] システムで[[閏秒]]を扱う試みもありましたが、
[[Unix time]] との整合性を維持できず失敗しました。

** 時間帯

[83] 
[[Unix time]] は [[UTC]] での [[Unix epoch]] からの経過時間を表しています。

[84] 
どこのどんな[[地方時]] ([[標準時]]、[[サマータイム]])
を使っていて、それが [[UTC]] どどれだけの[[時差]]があるのであっても、
その[[時差情報][時差の記述]]は [[Unix time]]
に含めることはできません。
[[Unix time]] はどの瞬間であるかだけを表します。

[EG[
[85] 
[[Unix time]]
[TIME[123456789]]
は、
[TIME[UTC の1973年11月29日21時33分9秒][1973-11-29T21:33:09Z]]を表します。
すなわち
[TIME[日本時間の昭和48(1973)年11月30日6時33分9秒][1973-11-29T21:33:09Z]]です。
]EG]

[86] [[時差]]に意味がある場合は、 [[Unix time]] とは別の方法で保持しなければなりません。

* 各言語・プロトコルの Unix time

[104] 
非常に多くの[[プラットフォーム]] ([[OS]]、[[プログラミング言語]]、
[[ライブラリー]]、[[プロトコル]]、[[アプリケーション]]など)
が
[[Unix time]] を採用しています。

[105] 
[[Unix time]] という実質的に同じ[[日時]]の表現でありながらも、
各[[プラットフォーム]]ごとにいろいろな[[データ型]]や構文が採用されています。
定義の方法としても、
[[POSIX]]
の定義を参照するものもあれば、同等のものを独自に定義するものもあります。
厳密に定義するものもあれば、[[行間を読む]]ことが期待される曖昧なものもあります。

[106] 
呼称も様々です。

** C と POSIX

[6] [[C言語]]は[[データ型]] ([CODE[typedef]]) [DFN[time_t]] を有しています [SRC[>>65]]。
[[ISO C]] はその値の精度や[[値域]]を定めていません [SRC[>>65]] が、
現在では[[実質]]すべての実装が [[POSIX]] の定める [DFN[Epoch][Unix Epoch]] すなわち
[TIME[1970年1月1日0時0分0秒 UTC][1970-01-01T00:00:00Z]] [SRC[>>18]] からの経過[[秒]]数
([DFN[Seconds Since the Epoch]]) [SRC[>>10]] の[[整数]]としています。
1970年未満については[[未定義]]としています [SRC[>>10]]。
伝統的には[[32ビット符号なし整数]]でしたが、
[[2038年問題]]があり[[64ビット符号なし整数]]への移行が進んでいます [SRC[>>66]]。

[68] 
[[C言語]]は更に[[構造体]] [DFN[[CODE[timespec]]]]
を定めています。 [CODE[timespec]] は
[[非負]]の [CODE[time_t]] の値を持つ [DFN[[CODE[tv_sec]]]] と、
[ [N[0]], [N[999999999]] ] の [CODE[long]] 値を持つ [DFN[[CODE[tv_nsec]]]]
の組で構成されます。[[ナノ秒]]精度の[[時刻]]の表現に使われます。 [SRC[>>65]]

[SEE[ これらを使う他の関数は [CODE[time.t]] ]]

-*-*-

[11] 
[[Perlにおける日時]]は[[プラットフォーム]]依存ですが、
ほとんどすべての場合 [[Unix time]] です。
場合によって[[小数]]の [[Unix time]] も使われます。
[SEE[ [[Perlにおける日時]] ]]

[71] 
[[Ruby]] の [CODE[Time][Time (Ruby)]] は [[Unix time]]
を使っています。[[値域]]は[[プラットフォーム]]依存です。
[SEE[ [CODE[Time][Time (Ruby)]] ]]


[REFS[
- [65] [CITE[ISO/IEC 9899:yyyy - n2310.pdf]] ([TIME[2018-11-12 09:13:34 +09:00]]) <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#page=287>
- [18] [CITE[Definitions]]
( ([TIME[2014-05-13 04:24:34 +09:00]] 版))
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_150>
- [10] [CITE[General Concepts]]
([TIME[2016-04-26 12:24:41 +09:00]] 版)
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15>
-- 移転: [CITE[General Concepts]] ([TIME[2019-04-16 19:09:46 +09:00]]) <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16>
- [66] [CITE@ja-jp[time_t ‐ 通信用語の基礎知識]] ([TIME[2019-04-16 19:04:11 +09:00]]) <https://www.wdic.org/w/TECH/time_t>
]REFS]

[74] [CITE@en[[[RFC 2783]] - Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0]], [TIME[2021-04-11T13:49:49.000Z]], [TIME[2021-04-12T08:41:36.180Z]] <https://tools.ietf.org/html/rfc2783#section-2>

[FIG(quote)[
[FIGCAPTION[
[29] [CITE[perlvms - search.cpan.org]]
([TIME[2017-02-13 00:40:55 +09:00]])
<http://search.cpan.org/dist/perl/pod/perlvms.pod#time>
]FIGCAPTION]

> The value returned by time is the offset in seconds from 01-JAN-1970 00:00:00 (just like the CRTL's times() routine), in order to make life easier for code coming in from the POSIX/Unix world.

]FIG]


** NFS 

[114] [[NFS]] の [DFN[[CODE[timeval]]]], [DFN[[CODE[nfstime3]]]]
は、
[[Unix time]] の [DFN[[F[[CODE[seconds]]]]]]
と[[ミリ秒]]数の [DFN[[F[[CODE[useconds]]]]]]
の[[構造体]]です。
[SRC[>>113]]

[REFS[
- [113] [CITE@en[[[RFC 1094]] - NFS: Network File System Protocol specification]], [TIME[2021-01-31T15:59:44.000Z]], [TIME[2021-03-12T08:54:59.902Z]] <https://tools.ietf.org/html/rfc1094#section-2.3.4>
- [115] [CITE@en[[[RFC 1813]] - NFS Version 3 Protocol Specification]], [TIME[2021-01-31T15:58:26.000Z]], [TIME[2021-03-12T09:00:10.197Z]] <https://tools.ietf.org/html/rfc1813#page-21>
]REFS]

** gzip

[55] [[gzip]] の [[MTIME]] は、 [[Unix time]] を[[小エンディアン]]の
4バイト[[符号無し整数]]で表したものです。

[56] ただし、[N[0]] は[[タイムスタンプ]]なしを表します。

** ext ファイルシステムのタイムスタンプ

[SEE[ [[extの日時形式]] ]]

** PGP の時刻

[FIG(quote)[
[FIGCAPTION[
[5] [CITE@en[RFC 4880 - OpenPGP Message Format]]
([TIME[2015-04-05 14:41:03 +09:00]] 版)
<https://tools.ietf.org/html/rfc4880#section-3.5>
]FIGCAPTION]

> A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC.

]FIG]

** DKIM の時刻

[13] 
[[RFC 4871]] が定義する [CODE(822)@en[[[DKIM-Signature]]:]]
[[頭欄]]の [CODE(822)@en[[[t]]=]] [[タグ]]の値は、
1970年1月1日0時0分0秒 ([[UTC]]) からの[[秒]]数とされています。
ただし、[[閏秒]]は数えません。 [[RFC 4871]] は、
実装に対して最低 10[SUP[12]] (≒ [[紀元後]]20万年、≒ 40ビット[[符号無し整数]])
までの値を扱えることを[['''推奨''']] ([['''SHOULD''']]) しています。
更に、[[サービス拒否攻撃]]防止のために、
12桁以上の値は[[無限大]]とみなして[['''構わない''']]
([['''MAY''']]) ともしています。

** SQL

[31] [[SQL]] では[[時間帯を持たない日時]]の[[データ型]]が使われることも多いですが、
その場合でも [[Unix time]] が使われることがあります。ここでの [[Unix time]]
は、本来の [TIME[1970年1月1日0時 UTC][0]] からの[[秒数]]ではなく、
[[地方時]]の[TIME[0時][00:00:00]]からの[[秒数]]とされています。

[20] [[MySQL]] では、 [CODE[UNIX_TIMESTAMP]] で[[日時]]を [[Unix time]] に、
[CODE[FROM_UNIXTIME]] で [[Unix time]] を[[日時]]に変換できます。

;; [32] [[SQLの日時形式]]も参照。

** OAuth の時刻

[2] [CODE(URI)@en[[[oauth_timestamp]]]] も [[Unix time]] 同等の定義となっています。

** OpenID の時刻

[FIG(quote)[
[FIGCAPTION[
[3] [CITE@en[Final: OpenID Connect Core 1.0 incorporating errata set 1]]
([TIME[2014-11-09 04:00:29 +09:00]] 版)
<http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.2>
]FIGCAPTION]

>  Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. 

]FIG]

** CDNI の時刻

[FIG(quote)[
[FIGCAPTION[
[21] [CITE@en[RFC 8006 - Content Delivery Network Interconnection (CDNI) Metadata]]
([TIME[2016-12-14 14:55:04 +09:00]])
<https://tools.ietf.org/html/rfc8006#section-4.3.4>
]FIGCAPTION]

> A time value expressed in seconds since the UNIX epoch (i.e., zero
hours, zero minutes, zero seconds, on January 1, 1970) Coordinated
Universal Time (UTC) '''['''POSIX''']'''.
> Type: Integer
>    Example time representing 09:00:00 01/01/2000 UTC:
946717200

]FIG]

[FIG(quote)[
[FIGCAPTION[
[22] [CITE@en[RFC 8007 - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers]]
([TIME[2016-12-14 14:58:50 +09:00]])
<https://tools.ietf.org/html/rfc8007#section-5.2.5>
]FIGCAPTION]

> A JSON number, seconds since the UNIX epoch (00:00:00 UTC on
1 January 1970).

]FIG]

** TLS の時刻

[FIG(quote)[
[FIGCAPTION[
[4] [CITE@en[RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2]]
([TIME[2015-02-19 08:58:15 +09:00]] 版)
<http://tools.ietf.org/html/rfc5246#section-7.4.1.2>
]FIGCAPTION]

>       
:gmt_unix_time:
The current time and date in standard UNIX 32-bit format
(seconds since the midnight starting Jan 1, 1970, UTC, ignoring
leap seconds) according to the sender's internal clock.  Clocks
are not required to be set correctly by the basic TLS protocol;
higher-level or application protocols may define additional
requirements.  Note that, for historical reasons, the data
element is named using GMT, the predecessor of the current
worldwide time base, UTC.

]FIG]

** VMS の時刻

[SEE[ [[VMSの日時形式]] ]]

** ASN.1

[126] [DFN[BinaryTime]] は、 [DFN[RFC 4049]]
で規定された [[ASN.1の日時形式]]の一種で、
[[Unix time]] を使っています。
[SRC[>>125]]

[REFS[
- [125] [CITE@en[rfc4049]], [TIME[2021-07-05T05:45:18.000Z]] <https://datatracker.ietf.org/doc/html/rfc4049>
]REFS]

** MessagePack Timestamp extension type

[116] 
[[MessagePack]]
は、
[DFN[Timestamp extension type]]
を定めています。
[[ビット長]]の異なる3種類があります。
[SRC[>>82]]

- [118] [DFN[timestamp 96 format]] - [[秒]] [[32ビット符号なし整数]]
- [119] [DFN[timestamp 64 format]] - [[秒]] [[34ビット符号なし整数]], [[ナノ秒]] [[30ビット符号なし整数]]
- [120] [DFN[timestamp 32 format]] - [[秒]] [[64ビット符号'''付き'''整数]], [[ナノ秒]] [[32ビット符号なし整数]]

[117] [[秒]]はいずれも [[Unix time]]。[[ナノ秒]]は [0, 999999999]。
[[仕様書]]に符号化・復号の方法が定められていますが、
[[ナノ秒]]に不正な値が与えられた時の検査は何もされていません。
[SRC[>>82]]
これは意図したものであるようですが [SRC[>>121]]、
その意図は不明です。
実装が厳密に検査するか否か、[[秒]]と[[秒未満]]を分けて保持するかどうかで、
挙動が変わってきそうで、
[[相互運用性]]・[[セキュリティー]]等の問題の温床にならないか懸念されます。

[REFS[
- [81] [CITE@ja[MessagePackフォーマット仕様にTimestamp型を追加 - Blog by Sadayuki Furuhashi]] ([TIME[2019-09-27 10:27:34 +09:00]]) <http://frsyuki.hatenablog.com/entry/2017/08/10/144310>
-
[82] [CITE@en[msgpack/spec.md at master · msgpack/msgpack]] ([TIME[2019-09-27 20:33:37 +09:00]]) <https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type>
- [121] [CITE@en[Proposal for timestamp type by frsyuki · Pull Request #209 · msgpack/msgpack · GitHub]], [TIME[2021-04-09T06:35:49.000Z]] <https://github.com/msgpack/msgpack/pull/209>
]REFS]



[73] [CITE@en[msgpack/spec.md at master · msgpack/msgpack]]
([TIME[2019-07-14 10:38:22 +09:00]])
<https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type>





** CBOR


[FIG(quote)[
[FIGCAPTION[
[58] [CITE@en[Concise Binary Object Representation (CBOR)]]
([TIME[2018-02-23 07:30:37 +09:00]])
<https://cbor-wg.github.io/CBORbis/#datetimesect>
(消滅確認 [TIME[2021-04-09T06:46:30.200Z]])
]FIGCAPTION]

> Tag value 1 is for numerical representation of seconds relative to 1970-01-01T00:00Z in UTC time. (For the non-negative values that the Portable Operating System Interface (POSIX) defines, the number of seconds is counted in the same way as for POSIX “seconds since the epoch” '''['''TIME_T''']'''.) The tagged item can be a positive or negative integer (major types 0 and 1), or a floating-point number (major type 7 with additional information 25, 26, or 27). Note that the number can be negative (time before 1970-01-01T00:00Z) and, if a floating-point number, indicate fractional seconds.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[43] [CITE@en[RFC 7049 - Concise Binary Object Representation (CBOR)]]
([TIME[2017-05-07 16:11:09 +09:00]])
<https://tools.ietf.org/html/rfc7049#section-2.4.1>
]FIGCAPTION]

> Tag value 1 is for numerical representation of seconds relative to
>    1970-01-01T00:00Z in UTC time.  (For the non-negative values that the
>    Portable Operating System Interface (POSIX) defines, the number of
>    seconds is counted in the same way as for POSIX "seconds since the
>    epoch" '''['''TIME_T''']'''.)  The tagged item can be a positive or negative
>    integer (major types 0 and 1), or a floating-point number (major type
>    7 with additional information 25, 26, or 27).  Note that the number
>    can be negative (time before 1970-01-01T00:00Z) and, if a floating-
>    point number, indicate fractional seconds.

]FIG]




** SGML, XML

[111] [[DSSSL]]:
[[JIS X 4153:1998]] 8.5.11
「[L[1970年1月1日午前0時0分0秒 (GMT) から経過した秒数を整数として]]」

[141] [TIME[2001-08-19T05:29:10.000Z]], [TIME[2023-11-23T08:36:37.306Z]] <http://www.y-adagio.com/public/standards/jis_dsssl/cls8.txt>

>
[PRE[
(time)
(time->string k)
(time->string k boolean)
]PRE]
手続きtimeは,1970年1月1日午前0時0分秒(GMT)から経過した秒数を整数として返す。手続きtime->stringは,手続きtimeが返す日付及び時間の整数表現をISO 8601の形式の文字列に変換する。引数booleanが存在し,それが真の場合,文字列表現はGMTに基づくものとなり,その他の場合に地方時間を示す。


[122] [[XFDLの日時処理]]

** その他

[FIG(short list)[ [127] [[Unix time]] の[[応用]]
- [CITE[[[JSON Timestamps]]]]
- [[MongoDB Extended JSON]]の時刻の一種
- [[Time component]]

]FIG]


-
[19] [CITE@en[WebDriver]]
([TIME[2016-07-22 07:24:31 +09:00]])
<https://w3c.github.io/webdriver/webdriver-spec.html#dfn-unix-epoch>
-- [107] 
移転確認 [TIME[2024-09-19T06:11:50.800Z]]
-- [108] 
[CITE@en-us[WebDriver]], [TIME[2024-07-23T11:04:13.000Z]], [TIME[2024-09-19T06:11:35.679Z]] <https://w3c.github.io/webdriver/#dfn-unix-timestamp>



[FIG(quote)[
[FIGCAPTION[
[61] [CITE[LHA解説書]]
([TIME[2012-10-06 14:39:51 +09:00]])
<http://techno7.co.jp/jimuki/new2000/lha/index.htm>
]FIGCAPTION]

> LHA では内部的にタイムスタンプを 1970-01-01 00:00:00 UTC からの通算秒
に変換しています。このため、実在しないスタンプ(80-00-00 など)を持った
ファイルを格納した場合、タイムスタンプは不定となります。

]FIG]

[62] しかし保存先は [[MS-DOSの日時形式]]らしい。


[FIG(quote)[
[FIGCAPTION[
[63] [CITE@ja-jp[LHAフォーマット ‐ 通信用語の基礎知識]]
([TIME[2018-10-14 01:39:52 +09:00]])
<https://www.wdic.org/w/TECH/LHA%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88>
]FIGCAPTION]

> 03h	DWORD	最終更新日時 (time_t形式)

]FIG]


[FIG(quote)[
[FIGCAPTION[
[64] [CITE[gzip-1.9 released '''['''stable''']''']]
([TIME[2018-01-08 08:44:44 +09:00]])
<https://lists.gnu.org/archive/html/info-gnu/2018-01/msg00004.html>
]FIGCAPTION]

>   When converting from system-dependent time_t format to the 32-bit
>   unsigned MTIME format used in gzip files, if a timestamp does not
>   fit gzip now substitutes zero instead of the timestamp's low-order
>   32 bits, as per Internet RFC 1952.  When converting from MTIME to
>   time_t format, if a timestamp does not fit gzip now warns and
>   substitutes the nearest in-range value instead of crashing or
>   silently substituting an implementation-defined value (typically,
>   the timestamp's low-order bits).  This affects timestamps before
>   1970 and after 2106, and timestamps after 2038 on platforms with
>   32-bit signed time_t.  '''['''bug present since the beginning''']'''

]FIG]


[FIG(quote)[
[FIGCAPTION[
[42] [CITE@en[RFC 7519 - JSON Web Token (JWT)]]
([TIME[2017-05-14 16:14:20 +09:00]])
<https://tools.ietf.org/html/rfc7519#section-2>
]FIGCAPTION]

> NumericDate
>       A JSON numeric value representing the number of seconds from
>       1970-01-01T00:00:00Z UTC until the specified UTC date/time,
>       ignoring leap seconds.  This is equivalent to the IEEE Std 1003.1,
>       2013 Edition '''['''POSIX.1''']''' definition "Seconds Since the Epoch", in
>       which each day is accounted for by exactly 86400 seconds, other
>       than that non-integer values can be represented.

]FIG]



[FIG(quote)[
[FIGCAPTION[
[98] [CITE@ja[SORACOM API 利用ガイド | SORACOM Users]]
([TIME[2020-03-26 00:33:24 +09:00]])
<https://dev.soracom.io/jp/docs/api_guide/#datetime>
]FIGCAPTION]

> API パラメータでは、UNIX Time(1970年1月1日からの経過秒数)を指定する箇所と、YYYYMMDD のようなフォーマットの文字列形式で指定する箇所がありますが、いずれも UTC で指定します。

]FIG]




[110] [CITE@en[GNU Coreutils: 28.9 Unix 紀元 (the Epoch) からの秒数]]
([TIME[2019-09-09T03:33:16.000Z]], [TIME[2020-10-20T09:12:42.541Z]])
<https://linuxjm.osdn.jp/info/GNU_coreutils/coreutils-ja_207.html>



[FIG(quote)[
[FIGCAPTION[
[128] [CITE@en[設定ファイルの仕様 | COCOA Open Source Project]]
([TIME[2021-11-25T07:16:26.000Z]], [TIME[2021-11-30T09:42:52.767Z]])
<https://cocoa-mhlw.github.io/cocoa/docs/appendix/preference_specification/#v130-->
]FIGCAPTION]

> 日付情報はUNIX Epoch(e.g. [CODE[1592528400]])

]FIG]




[FIG(quote)[
[FIGCAPTION[
[90] [CITE[VRML97, ISO/IEC 14772-1:1997 -- 3 Definitions]]
([TIME[2014-01-31 07:20:50 +09:00]])
<https://www.web3d.org/documents/specifications/14772/V2.0/part1/glossary.html#Time>
]FIGCAPTION]

> 3.99 time
> A monotonically increasing value generated by a node. Time (0.0) starts at 00:00:00 GMT January 1, 1970.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[91] [CITE[VRML97, ISO/IEC 14772-1:1997 -- 4 Concepts]]
([TIME[2014-01-31 07:20:50 +09:00]])
<https://www.web3d.org/documents/specifications/14772/V2.0/part1/concepts.html#4.11>
]FIGCAPTION]

> Time (0.0) is equivalent to 00:00:00 GMT January 1, 1970. Absolute times are specified in SFTime or MFTime fields as double-precision floating point numbers representing seconds. Negative absolute times are interpreted as happening before 1970.

]FIG]


[92] [CITE[VRML97, ISO/IEC 14772-1:1997 -- 5 Field and Event Reference]]
([TIME[2014-01-31 07:20:50 +09:00]])
<https://www.web3d.org/documents/specifications/14772/V2.0/part1/fieldsRef.html#SFTime>



[FIG(quote)[
[FIGCAPTION[
[51] [CITE@en[GitHub API v3 | GitHub Developer Guide]]
([TIME[2017-06-10 05:53:45 +09:00]])
<https://developer.github.com/v3/#rate-limiting>
]FIGCAPTION]

> The time at which the current rate limit window resets in UTC epoch seconds.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[52] [CITE@en[docker service logs | Docker Documentation]]
([TIME[2017-06-10 10:22:13 +09:00]])
<https://docs.docker.com/engine/reference/commandline/service_logs/#extended-description>
]FIGCAPTION]

> When providing Unix timestamps enter seconds'''['''.nanoseconds''']''', where seconds is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a fraction of a second no more than nine digits long.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[53] [CITE[取引所APIドキュメント | Coincheck(コインチェック)]]
([TIME[2017-06-22 11:12:30 +09:00]])
<https://coincheck.com/ja/documents/exchange/api>
]FIGCAPTION]

> ACCESS-NONCE 毎リクエストごとに増加する必要のある正の整数。通常はUNIXタイムスタンプを用います。最大値は 9223372036854775807 です。APIキーごとに管理されます。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[57] [CITE@en[Git - git-commit Documentation]]
([TIME[2018-03-04 14:30:18 +09:00]])
<https://git-scm.com/docs/git-commit#_date_formats>
]FIGCAPTION]

> Git internal format
> It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.

]FIG]




[REFS[

[FIG(quote)[
[FIGCAPTION[
[145] 
[CITE@en[How to convert dates to Unix timestamps in ClickHouse®]], [TIME[2026-01-01T09:52:55.000Z]] <https://www.tinybird.co/blog/convert-date-to-unix-timestamp-clickhouse>
]FIGCAPTION]

>Use [CODE[toUnixTimestamp64()]] or cast results to UInt64 for dates after 2038. Standard [CODE[toUnixTimestamp()]] returns UInt32 which overflows in 2038, causing incorrect results for future dates. The 64-bit variants handle dates well beyond the current millennium.

]FIG]

]REFS]


* ミリ秒Unix time

[137] 
[[Java]] などで[[単位]]を[[ミリ秒]]とする[DFN[ミリ秒Unix time]]が使われています。

[136] 
[[BSON]] の[[UTC datetime]]が[[ミリ秒Unix time]] です。
[[MongoDB Extended JSON]] の日付の一種も[[ミリ秒Unix time]]です。

** [DFN[Java時刻]]、[DFN[JavaScript時刻]]

[14] [[Java]] の [CODE[Calendar]] [SRC[>>27]] や
[[JavaScript]] の [CODE(JS)@en[[[Date]]]] の値も [[Unix time]]
と同じ[[元期]]ですが、[[ミリ秒]][[単位]]となっています。 (こちらも[[閏秒]]は考えません。)

[154] 
[[Java]] は [CODE[long]] ([[64ビット符号付き整数]])、
[[JavaScript]] は [[number]] ([[倍精度浮動小数点数]])
なので[[値域]]は違います。

[24] [[DOM]] の[[日時]]を扱う [[API]] ([CODE[DOMTimeStamp]]) も、
[[ミリ秒]]単位の千倍 [[Unix time]] を用いています。

;; [45] [[JavaScriptの日時形式]]も参照。

[46] 
[[DateTime Wire Format]] でも使われています。


[REFS[

[FIG(quote)[
[FIGCAPTION[
[97] 
[CITE@en-US[Push API]], [TIME[2020-02-04 16:21:34 +09:00]] <https://w3c.github.io/push-api/#dfn-subscription-expiration-time>
]FIGCAPTION]

>time, in milliseconds since 00:00:00 UTC on 1 January 1970

[SEE[ [[購読満期時刻]] ]]

]FIG]

[FIG(quote)[
[FIGCAPTION[
[27] [CITE@en[Calendar (Java Platform SE 7 )]]
([TIME[2014-02-20 11:18:28 +09:00]])
<http://docs.oracle.com/javase/jp/7/api/java/util/Calendar.html>
]FIGCAPTION]

> 特定の時点は、1970 年 1 月 1 日 00:00:00.000 GMT (グレゴリオ暦) を元期とするミリ秒単位のオフセットで表現できます。

]FIG]

]REFS]




[30] [CITE@en[File API]]
([TIME[2017-02-11 03:25:10 +09:00]])
<https://w3c.github.io/FileAPI/#UnixEpoch>


[FIG(quote)[
[FIGCAPTION[
[50] [CITE@ja-jp[タイムスタンプ型 | CQL for Cassandra 2.x]]
([TIME[2017-05-23 01:28:12 +09:00]])
<https://docs.datastax.com/ja/cql-jajp/3.1/cql/cql_reference/timestamp_type_r.html>
]FIGCAPTION]

> タイムスタンプ型の値は64ビットの符号付き整数としてエンコードされ、エポックとして知られる標準基準時間(1970年1月1日、GMT時間0時0分0秒)からのミリ秒数を表します。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[44] [CITE@en[レシートのフィールド]]
([TIME[2017-05-18 00:39:47 +09:00]])
<https://developer.apple.com/jp/documentation/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html>
]FIGCAPTION]

> 定期購読の有効期限が、1970年1月1日 00:00:00 GMTからのミリ秒単位で表されています。
> ASN.1フィールドタイプ:1708
> ASN.1フィールド値: IA5STRING(RFC 3339の日付として解釈されます)
> JSONフィールド名:expires_date
> JSONフィールド値:数値

]FIG]


[FIG(quote)[
[FIGCAPTION[
[48] [CITE@ja[プログラマーの常識をJavaで身につける(4):OSとプログラミングの「時間」に関する常識 (1/3) - @IT]]
([TIME[2017-06-08 18:49:20 +09:00]])
<http://www.atmarkit.co.jp/ait/articles/0703/28/news135.html>
]FIGCAPTION]

> 具体的には、1970年1月1日 00:00:00 GMTからのミリ秒数を表すlong値として表現されています。この原稿では、これを便宜的に「エポックからのミリ秒」と呼ぶことにします。なお、1970年1月1日 00:00:00 GMTについてJava言語APIでは、「エポック」と呼んでいます。

]FIG]


[54] [CITE@en[Make Event's timeStamp use DOMHighResTimeStamp]]
([[majido]]著, [TIME[2017-07-13 16:38:55 +09:00]])
<https://github.com/whatwg/dom/commit/912d58746bc4c67c2fd210124639f7c34991fce5>


[FIG(quote)[
[FIGCAPTION[
[96] [CITE[Ink Markup Language (InkML)]]
([TIME[2018-10-09 22:24:24 +09:00]])
<https://www.w3.org/TR/2011/REC-InkML-20110920/#timestamp>
]FIGCAPTION]

> time = xsd:decimal
> The absolute time for this timestamp, in milliseconds since 1 January 1970 00:00:00 UTC.
> Required: no, Default: none.

]FIG]



[129] [CITE@ja-jp[DateTimeOffset.ToUnixTimeMilliseconds メソッド (System) | Microsoft Docs]]
([[dotnet-bot]], [TIME[2021-11-30T09:52:24.000Z]])
<https://docs.microsoft.com/ja-jp/dotnet/api/system.datetimeoffset.tounixtimemilliseconds?view=net-6.0#System_DateTimeOffset_ToUnixTimeMilliseconds>



* ナノ秒Unix time

[138] 
[[Go言語]]などで[[単位]]を[[ナノ秒]]とする[DFN[ナノ秒Unix time]]が使われています。


[149] [CITE@en-us[Date nanoseconds field type | Elasticsearch Guide '''['''8.11''']''' | Elastic]], [TIME[2023-11-24T15:20:54.000Z]], [TIME[2023-11-25T08:49:54.880Z]] <https://www.elastic.co/guide/en/elasticsearch/reference/current/date_nanos.html>

>The [CODE[date_nanos]] data type stores dates in nanosecond resolution, which limits its range of dates from roughly 1970 to 2262, as dates are still stored as a long representing nanoseconds since the epoch.



** [DFN[Go時刻]]

[34] [[Go]] の [DFN[[CODE[Time][Time (Go)]]]] は、[[ナノ秒]]単位の [[Unix time]]
を用いています。

[REFS[
[FIG(quote)[
[FIGCAPTION[
[33] [CITE[time - The Go Programming Language]]
([TIME[2017-03-10 18:17:34 +09:00]])
<https://golang.org/pkg/time/#Time>
]FIGCAPTION]

> The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC. 

]FIG]
]REFS]



[FIG(quote)[
[FIGCAPTION[
[35] [CITE[time - The Go Programming Language]]
([TIME[2017-03-10 18:22:09 +09:00]])
<https://golang.org/pkg/time/#Time.UnixNano>
]FIGCAPTION]

> UnixNano returns t as a Unix time, the number of nanoseconds elapsed since January 1, 1970 UTC. 

]FIG]





* 日単位 Unix time

[100] 
[[tantek]]
は[[短縮URL]]
で
[[Unix epoch]]
からの経過[[日]]数を
[[New Base 60]]
で記述し、
[DFN[epoch days]]
と呼んでいます。
[SRC[>>101]]

[EG[
[102] 
[CODE[4432]]
は[TIME[2010-02-03]]を表します。
[SRC[>>101]]
]EG]


[REFS[

[FIG(quote)[
[FIGCAPTION[
[101] [CITE[[[tantek]] / Whistle]], [TIME[2020-10-02T06:54:32.000Z]] <http://tantek.pbworks.com/w/page/21743973/Whistle>
]FIGCAPTION]

>After that I use a 3 digit sexagesimal (Base60) number to represent the date in a manner deliberately limited to human individuals. Why Base60? Lots of reasons, including print-safety (as mentioned above). Want to read the entire derivation and reasons why? See [[NewBase60]] (includes open source CASSIS implementation).
>
Why 3 sexagesimal digits to represent the date? It turns out that 3 sexagesimal digits are capable of representing over 500 years of days - plenty overengineered for any human lifetime. And if anyone does figure out how to live more than 500 years I have a feeling that person will not only not resemble human as we know it very much, but will either have bigger problems to deal with than URL shortener limitations, or will be so smart that they will come up with a better solution.
>
But for now, for our feeble less than 200 year lifetimes, this is good enough. In addition we can even agree on a day zero that computes well with existing platforms. Unix Epoch start: 1970-01-01. Given that no-one published anything to the web before 1990, I think we're ok with that. What happens in a few hundred years? Perhaps people can pick their own day zeroes as they see fit.
>
Thus the 3 characters after the "t" represent the number of days since 1970-01-01 in sexagesimal - what I'm calling "epoch days".

]FIG]

]REFS]


[150] [CITE@en[std::chrono::system_clock - cppreference.com]], [TIME[2023-11-16T07:47:35.000Z]], [TIME[2023-11-25T09:33:29.643Z]] <https://en.cppreference.com/w/cpp/chrono/system_clock>

>
,"The epoch of [CODE[system_clock]] is unspecified, but most implementations use Unix Time (i.e., time since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds).",	(until C++20)
,"[CODE[system_clock]] measures Unix Time (i.e., time since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds).",	(since C++20)

[151] >>150
[CODE[std::chrono::seconds]] を使うと[[秒]]数になり、
[CODE[std::chrono::days]] を使うと[[日]]数になります。


* 月単位 Unix time

[132] [[Unix epoch]] を[[元期]]とし、[[月]]を[[単位]]とする[[日時系]]がいくつかあります。

[133] [[ミリ秒Unix time]]などとは違って、[[暦月]]を[[単位]]とした数え方は通常の
[[Unix time]] の倍数ではないことに注意が必要です。[[暦月]]は[[月]]ごとに長さが違うので、
通常の [[Unix time]] とそのまま相互変換することができません。

[139] [[Unix epoch]] を [N[0]] とする[[グレゴリオ月]]単位の数え方: [[HTML月数]]

[140] [[Unix epoch]] を [N[0]] とする[[朔望月]]単位の数え方: [[月時計]]

* 桁溢れ問題

[76] 
[[Unix time]] の値を保存する[[データ型]]次第で、[[日時桁溢れ問題]]が発生します。



- [182] 
[CITE@ja[Xユーザーの狩野英孝さん: 「大阪へやってきました(^_^)v久しぶりにジャルジャルさんと仕事です(#^_^#)」 / X]], [TIME[午後11:07 · 1992年9月2日][1992-09-02T14:07:12.000Z]], [TIME[2026-03-26T06:21:15.000Z]] <https://x.com/kano9x/status/145669840114425857>
-- [183] 
[CITE@ja[Xユーザーの祥太さん: 「狩野英孝さんが1992年(平成4年)9月2日に飛ばされた理由がわかった。 このツイートの本来の時刻は、2011年12月11日 10:02:50(JST)。「from:kano9x since:2011-12-11_10:02:50_JST until:2011-12-11_10:02:51_JST」で検索するとこのツイートが出てくることからわかる。」 / X]], [TIME[午前3:56 · 2026年3月25日][2026-03-24T18:56:21.000Z]], [TIME[2026-03-26T06:21:15.000Z]] <https://x.com/shota_/status/2036517492378705927>



** 0値、負値

[8] [CITE@ja[iPhoneを「1970年1月1日」に設定すると利用不能になる問題、Appleがソフト更新で解消へ - ITmedia ニュース]]
([TIME[2016-02-17 19:58:04 +09:00]] 版)
<http://www.itmedia.co.jp/news/articles/1602/16/news132.html>

[9] [CITE@ja[iPhoneで「1970年1月1日」に設定すると使用不能に? 実際に試してみた - ITmedia Mobile]]
([TIME[2016-02-17 19:59:19 +09:00]] 版)
<http://www.itmedia.co.jp/mobile/articles/1602/12/news125.html>



** 10進10桁化

[144] 
[[Unix time]] の[[10進表現]]は[TIME[平成13(2001)年][2001]]に9桁で表現できなくなりました。
前年の[TIME[平成12(2000)年][2000]]の[[西暦2000年問題]]に関連して危険日としてよく紹介されていました
([DFN[西暦2001年9月9日問題]])。
大きな問題は報告されていません。
[SRC[>>143, >>142]]

[REFS[

- [143] [CITE@en-US[Unix Tick Tocks to a Billion | WIRED]], [[Condé Nast]], 
Sep 8, 2001 2:00 AM,
[TIME[2023-11-25T05:51:40.000Z]] <https://www.wired.com/2001/09/unix-tick-tocks-to-a-billion/>
- [142] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T05:51:24.631Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2001>

]REFS]

[157] 
[CITE@ja[Windows Meに2001年9月9日問題 | スラド]], [TIME[2024-01-25T08:05:28.000Z]] <https://srad.jp/story/01/06/12/0626230/>

[FIG(quote)[
[FIGCAPTION[
[26] [CITE@ja[電子機器の時刻]]
([TIME[2017-01-09 16:22:34 +09:00]])
<http://www.ffortune.net/calen/calen/etime.htm>
]FIGCAPTION]

> 2001年9月9日1時46分40秒にこの数字が十進数で9桁から10桁に変わりました。2chなどではこの数字を掲示板のidに使用しているため、この前後での掲示板の並べ替えがうまく行きません。 

]FIG]



[87] [CITE[9月 9日 コンピュータの9月9日問題が発生(2001年)(ブルーバックス編集部) | ブルーバックス | 講談社]]
([TIME[2019-11-10 09:37:51 +09:00]])
<https://gendai.ismedia.jp/articles/-/66915>


** 西暦2038年問題

[59] 
[DFN[西暦2038年問題]]は、
[[Unix time]]
の[[桁溢れ問題]]です。
[TIME[令和20(2038)年][2038]]に [[Unix time]] が[[32ビット整数]]で表現できなくなること、
およびそれに起因する諸問題であります。
[SEE[ [[西暦2038年問題]] ]]




** 西暦2106年問題とそれ以降

[75] 
[[西暦2038年問題]]の次は[DFN[西暦2106年問題]]とされます。

[148] 
[CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T07:58:03.547Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2106>

>Many existing file formats, communications protocols, and application interfaces employ a variant of the Unix [CODE[time_t]] date format, storing the number of seconds since the Unix Epoch (midnight UTC, 1 January 1970) as an unsigned 32-bit binary integer. This value will roll over on 7 February 2106 at 06:28:15. That is, at this time the number of seconds since 1 January 1970 is FFFF FFFF in hex. 

[152] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T09:41:30.433Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2286>

>Systems that use a string of length 10 characters to record the Unix time may have problems reporting times beyond the ten-billionth second after 20 November 2286, at 17:46:40. 


[135] 
[[西暦2232年問題]]



- [159] [CITE@ja[西暦2262年問題に対処するべきか | 雑記帳]], [TIME[2024-03-24T13:03:23.000Z]] <https://blog.miz-ar.info/2024/03/year-2262-problem/>
- [160] [CITE@ja[Xユーザーのmod_poppoさん: 「今から書くコードが2038年を過ぎても動作しなければならないのはいいとして、2262年を過ぎても動作した方が良いかは少し考えてしまう(1970年からナノ秒単位で数えた時に符号付き64ビット整数で表現できる範囲を超えるのが2262年)」 / X]], [TIME[午後6:24 · 2024年3月23日][2024-03-23T09:24:17.000Z]], [TIME[2024-03-24T12:48:51.000Z]] <https://twitter.com/mod_poppo/status/1771467998898827671>
-- [161] アンケート202票中、80.7%が対応不要

[77] [DFN[西暦2486年問題]]

[78] [[西暦2038年問題]]の対策のいくつかは[TIME[西暦2486年][2486]]まで延命するものです。
[SEE[ [[西暦2038年問題]] ]]

* Unix time と称する Unix time ではないもの

[28] [[TAI]] を[[元期]]とするものは [[TAI64]] 参照。


[FIG(quote)[
[FIGCAPTION[
[123] [CITE@ja[第66回 モジュールによる時間の多様な取り扱い(1):Perl Hackers Hub|gihyo.jp … 技術評論社]]
([TIME[2021-04-19T00:15:00.000Z]], [TIME[2021-04-19T11:29:21.509Z]])
<https://gihyo.jp/dev/serial/01/perl-hackers-hub/006601>
]FIGCAPTION]

> UNIX時間は,例外的にClassic Mac OSなど一部の古いシステムでは,UTC1904年1月1日00:00:00が紀元になることがあります。

]FIG]

[47] [[UNIX時間]]と称しているが、実際には [[1904 time system]] のこと。

* メモ

[1] ''スラッシュドット ジャパン | 明日でepochから2^30秒'' <http://slashdot.jp/article.pl?sid=04/01/08/172200&mode=flat&commentsort=4&threshold=-1>

[16] [CITE@ja[time_t - Wikipedia]]
( ([TIME[2014-04-22 06:59:21 +09:00]] 版))
<http://ja.wikipedia.org/wiki/Time_t>

[17] [CITE@en[Unix time - Wikipedia, the free encyclopedia]]
( ([TIME[2014-05-11 13:26:43 +09:00]] 版))
<http://en.wikipedia.org/wiki/Unix_time>

















[36] [CITE@en[SANS Digital Forensics and Incident Response Blog | Understanding EXT4 (Part 2): Timestamps | SANS Institute]]
([TIME[2017-03-10 19:07:34 +09:00]])
<https://digital-forensics.sans.org/blog/2011/03/14/digital-forensics-understanding-ext4-part-2-timestamps>

[39] [CITE@en[Add PushSubscription.expirationTime (#248)]]
([[beverloo]]著, [TIME[2017-04-19 02:15:13 +09:00]])
<https://github.com/w3c/push-api/commit/73da6411aac80de7de9bf5e65ee8eb4cc6a9aa24>

[40] [CITE@en[Epoch (astronomy) - Wikipedia]]
([TIME[2017-05-08 07:11:20 +09:00]])
<https://en.wikipedia.org/wiki/Epoch_(astronomy)>

[41] [CITE[General Concepts]]
([TIME[2017-05-15 17:06:25 +09:00]])
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16>





[FIG(quote)[
[FIGCAPTION[
[49] [CITE[日付関数またはタイムスタンプ関数の日付部分 - Amazon Redshift]]
([TIME[2017-06-08 07:42:07 +09:00]])
<http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_Dateparts_for_datetime_functions.html>
]FIGCAPTION]

> Amazon Redshift の EPOCH の実装は、サーバーのあるタイムゾーンから独立した 1970-01-01 00:00:00.000000 に関連します。

]FIG]





[60] [CITE@en[Unix time - Wikipedia]]
([TIME[2018-09-29 18:11:15 +09:00]])
<https://en.wikipedia.org/wiki/Unix_time>


[80] [CITE@en[Package google.protobuf  |  Protocol Buffers  |  Google Developers]]
([TIME[2019-06-20 23:04:44 +09:00]])
<https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#google.protobuf.Timestamp>



[112] [CITE@ja[Arthur David OlsonさんはTwitterを使っています 「It's Salute to the Seventies day at the @SSTransitCenter. Guess: a UNIX-derived computer operating on UTC drives this display and crashed 17 minutes before I captured this image. https://t.co/G3b12GQDue https://t.co/9Ze5qUN5ME」 / Twitter]]
(午前4:22 · 2021年2月2日 [TZ[+09:00]], [TIME[2021-02-01T12:13:06.000Z]])
<https://twitter.com/dashdashado/status/1356321947005628418>




[130] [CITE@ja[10億秒 | スラド]]
([TIME[2022-02-24T05:35:37.000Z]])
<https://srad.jp/story/01/09/08/1027223/>