NTP ↔ Unix タイムスタンプ
Unix時間の0はNTPの2208988800と同じで、どちらも1970年1月1日午前0時を、異なる起点から数えた値です。一方の数値をもう一方に変換し、対応する日時もISO 8601形式で確認できます。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 変換方向
- Unix to ntp
- Unix タイムスタンプ(秒)
- 0
- NTP タイムスタンプ(秒)
- 2,208,988,800
- ISO 日時
- 1970-01-01T00:00:00.000Z
NTP タイムスタンプ(1900年1月1日からの経過秒数)を Unix 時刻や ISO-8601 形式へ、またその逆方向へと、ネットワーク接続なしで変換します。
数え始めの年が違う2つの時計
NTPタイムスタンプとUnixタイムスタンプは、どちらも時間を単純な秒数で表しますが、数え始める日付が異なります。NTPは1900年1月1日の最初の1秒から、Unix時間は1970年1月1日から数えます。2つの時計は同じ速さで進むため、その差は変わらず、常に2208988800秒です。そのため、Unix時間の0とNTPの2208988800は同じ瞬間を指します。変換は引き算か足し算1回で済み、変換ツールはその瞬間をひと目で分かる日付と時刻でも表示します。
この変換で防げるよくある間違い
最も多い間違いは、起点を取り違えて値を読むことです。NTPの数値をUnix時間として読むと数十年先の日付になり、Unixの数値をNTPとして読むと1900年近くまで戻ってしまいます。変換の向きをはっきり選ぶことで、この迷いはなくなります。また、空の入力や数値ではない値は計算の前に受け付けないため、入力ミスはもっともらしい誤った日付ではなく、分かりやすいメッセージになります。結果は毎回同じ方法で計算され、インターネット上の情報を参照することもありません。
境界条件と制限
空の文字列、誤った型、そして矛盾する範囲は、いかなる計算が行われるよりも前の、できるだけ早い段階で拒否されます。タイムゾーンを持たない暦日は、暗黙の時差を仮定することなく、そのまま暦上の日付として解釈されます。
埋め込まれたテーブルはこの機能のフォルダー内に同梱されて移動し、実行時にはネットワーク呼び出しが一切行われないため、オンラインでもオフラインでも同一の結果が保証されます。表現可能な範囲を外れた NTP タイムスタンプは、近似的な結果ではなく明確なエラーを引き起こします。統合を始める前に、この機能の契約を固定する基準サンプルをぜひご検討ください。
活用例
日常業務
表計算ソフトを使わずに信頼できる答えが得られます。
教育
デモ向けの安定した基準サンプルをご利用いただけます。
よくある質問
NTPタイムスタンプとは何ですか?
1900年1月1日から経過した秒数です。Unixタイムスタンプは同じ秒を1970年1月1日から数えるので、2つの数値が同じ瞬間を表すことがあります。
NTPタイムスタンプをUnix時間に変換するには?
2つの起点の間の秒数である2208988800を引きます。逆にUnixの値に2208988800を足すと、NTPの値になります。
NTPの値2208988800はいつに当たりますか?
Unix時間の0、つまりUTCで1970年1月1日の始まりです。変換ツールではその瞬間が1970-01-01の午前0時として表示されます。
両方向に変換できますか?
はい。NTPの値から始めるかUnixの値から始めるかを選び、数値を入力すると、もう一方の数値と、それが表す日時が表示されます。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/date/ntp-timestamp \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"direction":"unix_to_ntp","unix_seconds":0}'const res = await fetch("https://api.kit.forhosting.com/date/ntp-timestamp", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"direction": "unix_to_ntp",
"unix_seconds": 0
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/ntp-timestamp",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"direction": "unix_to_ntp",
"unix_seconds": 0
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/ntp-timestamp", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"direction":"unix_to_ntp","unix_seconds":0}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"direction":"unix_to_ntp","unix_seconds":0}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/ntp-timestamp", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"direction": "unix_to_ntp",
"unix_seconds": 0
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.ntp_timestamp",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
動作の仕組み
このツールは、1900年1月1日からの経過秒数で表される NTP タイムスタンプを、Unix 時刻および ISO-8601 形式へ、さらにその逆方向へと変換します。本番のワークフローや自動テストへ組み込む前に、成功時と失敗時の両方について、基準となるサンプルを注意深くお読みになることをお勧めします。計算は完全に決定的であり、API とまったく同じ純粋関数を用いて、お使いのブラウザー上で無料で実行されます。入力値はあらゆる算術演算に先立って検証されるため、型が誤っている場合には曖昧な結果ではなく、明確な invalid_input エラーが返されます。付属のドキュメントでは、検証の順序、結果の再現性、ブラウザーと API の一致、認証のための安定したエラー照合文字列、そして範囲外の浮動小数点値を安全に扱う方法について詳しく説明しています。
入力と出力
本番環境や自動テストへ統合される前に、成功時と失敗時の両方の基準サンプルを必ずご確認ください。スキーマの必須フィールドは、処理が始まる前に必ず存在し、正しい型で指定されている必要があります。任意のフィールドには文書化された既定値が用いられるため、動作はどのような状況でも予測可能なものとなります。成功時の応答には主要な出力フィールドが常に含まれており、お使いのインターフェースのバインディングが時間の経過とともに安定して保たれます。IEEE-754 の精度を超えるきわめて大きな中間値は、診断の難しい静かな null 値ではなく、明示的な範囲超過エラーとして返されます。ドキュメントでは、検証の順序、結果の決定性、ブラウザーと API の一致、そして認証の際に用いられるエラー照合文字列について述べています。
境界条件と制限
ドキュメントはさらに、検証の順序、決定性、ブラウザーと API の一致、そして許容範囲外の浮動小数点値を慎重に扱う方法についても取り上げています。
連携の活用例
自動化
ウィジェットと API で同一の純粋関数を使用します。
技術的な質問
無料ですか?
はい、ブラウザー内のティア A で無料です。
ネットワークは?
ネットワークは不要で、端末上で解析します。
無効な入力は?
明確な照合文字列を伴う invalid_input エラーになります。
安定していますか?
決定的な基準サンプルが契約を固定します。
作者は?
samurai。