時刻

4 tools

ToolDeckの時間ツールを使えば、Unixタイムスタンプの変換、Cron式の解析、Cronスケジュールのビジュアル生成、Cron構文の検証をブラウザ上で直接行えます。タイムスタンプコンバーターは、Unixエポック値と主要なフォーマットの人間が読める日付を相互変換します。Cron式パーサーはCron文字列を平易な言葉の説明に分解し、次回実行時刻のプレビューを表示します。Cron式ジェネレータは手入力なしにステップバイステップのビジュアルインターフェースでCron式を構築します。Cron式バリデーターはCron構文を検証し、各コンポーネントのフィールド別詳細を表示します。すべての処理はブラウザ内でローカルに実行され、サーバーへの通信なし、アカウント不要、データ収集なしで利用できます。

ログやAPIのエポック値を変換する際はタイムスタンプコンバーター、既存のスケジュールを平易な言葉にデコードする際はCron式パーサー、新しい式をビジュアルで構築する際はCron式ジェネレータ、本番環境にデプロイする前に構文を確認する際はCron式バリデーターをご利用ください。

時間ツールとは?

時間ツールは、開発者が日付・タイムスタンプ・スケジュール実行を扱う際に直面する実際の問題を解決します。Unixタイムスタンプはデータベースのカラム、APIレスポンス、ログファイル、JWTクレームに現れます。インシデント対応中に1717200000のような生の値を読むには、人間が読める日付への変換が必要です。Cron式はCI/CDの設定ファイル、Kubernetesマニフェスト、サーバーのcrontabに記述されます。0 9 * * 1-5と書いて平日の午前9時(週末は除く)に確実に実行されるかどうかを確認するには、パーサーまたはバリデーターが必要です。

時間ツールは2つの領域に分かれます。タイムスタンプ変換は、Unixエポック値(1970-01-01 00:00:00 UTCからの秒またはミリ秒)とフォーマット済み日付文字列を相互変換します。主に関係する標準は、ISO 8601(国際標準化機構が定める国際的な日付/時刻フォーマット)、RFC 3339(IETFが公開したISO 8601のインターネットプロファイル)、RFC 2822(メールヘッダーとHTTPで使用される日付フォーマット)です。Cron式ツールは、POSIX(IEEE Std 1003.1)で元々定義された5フィールドのスケジュール構文の解析・生成・検証を担います。この構文は現在、crontab、systemdタイマー、GitHub Actions、Kubernetes CronJob、AWS EventBridgeやGoogle Cloud Schedulerなどのクラウドスケジューラーで広く使用されています。

開発者がこれらのツールを使うのは、デバッグ時(ログやデータベース行のタイムスタンプ変換)、デプロイ前(Cronスケジュールの作成と本番投入前の検証)、コードレビュー時(同僚のCron式が意図したスケジュールと一致するかの確認)です。QAエンジニアはタイムスタンプ変換を使ってAPIレスポンスが正しい日付値を含むか検証します。DevOpsエンジニアはCronツールを使ってバックアップスケジュール、ログローテーション、証明書更新ジョブを設定します。

ToolDeckの時間ツールを使う理由

ToolDeckの時間ツールはすべてブラウザ内で動作します。タイムスタンプとCron式はJavaScriptでローカルに処理されるため、データが外部に送信されることはありません。各ツールは単一のタスクに特化しており、サインアップなし・レート制限なしで即座に読み込まれます。

🔒
ブラウザのみで処理
すべての変換・検証はデバイス上のJavaScriptで実行されます。APIコール、サーバーログ、データ保持は一切ありません。本番データベースのタイムスタンプや社内のCronスケジュールはデバイス上に留まります。
即時結果
Unixタイムスタンプまたは Cron式を貼り付ければ、結果が即座に表示されます。往復の遅延なし、キューなし、ローディング表示なしです。
📐
標準準拠の出力
タイムスタンプ変換はISO 8601(RFC 3339)およびRFC 2822形式で出力します。Cron解析はPOSIXの5フィールド形式に加え、秒フィールド、L(最終)、W(最も近い平日)、#(第n曜日)などの一般的な拡張構文をサポートします。
🔓
アカウント不要
ページを開いてすぐに作業を始められます。登録不要、APIキー不要、利用上限なし。ツールをブックマークして必要なときにいつでも使えます。

時間ツールの使用例

タイムスタンプとCronの問題は、バックエンド・DevOps・QAの業務全般で頻繁に発生します。

ログ分析
アプリケーションログのエポックタイムスタンプを読みやすい日付に変換し、インシデント調査中のイベントを関連付けます。10桁か13桁の値が秒かミリ秒かを素早く判断できます。
CI/CDスケジューリング
コミット前にGitHub Actionsワークフロー、Jenkinsパイプライン、GitLab CIスケジュールのCron式を生成・検証します。次の5回の実行時刻をプレビューしてスケジュールを確認できます。
Kubernetes CronJobの設定
Cron式を解析して次回実行時刻をプレビューし、意図したKubernetes CronJobのスケジュールと一致するか確認します。
データベースのデバッグ
データ問題を調査しながら、データベースのカラムに保存されたUnixタイムスタンプを人間が読める日付に変換します。
監視とアラート
Prometheusのアラートルール、Grafanaのレポートスケジュール、PagerDutyのメンテナンスウィンドウ用にCron式を作成します。TerraformまたはHelmの設定に追加する前に構文を検証します。
APIレスポンスの検査
REST APIが返すエポックタイムスタンプをデコードし、created_at、updated_at、expires_atフィールドが期待値を含むか検証します。

時間フォーマットとCron構文リファレンス

2つの領域を理解しておきましょう:API、データベース、ログで使用されるタイムスタンプフォーマットと、Unix cron、Kubernetes、GitHub Actions、クラウドスケジューラーで使用されるCron式の構文です。

よく使われるタイムスタンプフォーマット

フォーマット標準 / 備考
1717200000Unix秒POSIX / IEEE Std 1003.1
1717200000000Unixミリ秒JavaScript Date.now(), Java
2024-06-01T00:00:00.000ZUTCとミリ秒ISO 8601 / RFC 3339
2024-06-01T00:00:00+02:00UTCオフセット付きISO 8601 / RFC 3339
Sat, 01 Jun 2024 00:00:00 +0000メール / HTTPヘッダーRFC 2822
2024-06-01日付のみISO 8601 (calendar date)

Cron式のフィールド

フィールド許容値特殊文字
0–59* , - /
0–23* , - /
日(月内)1–31* , - / ? L W
1–12 or JAN–DEC* , - /
曜日0–6 or SUN–SAT* , - / ? L #

標準の5フィールドcron(分から曜日まで)はPOSIX(IEEE Std 1003.1)で定義されており、crontab、systemd、Kubernetes CronJob、GitHub Actions、ほとんどのCI/CDプラットフォームで使用されています。QuartzやSpringなど一部のシステムは秒フィールドを6番目のフィールドとして追加しています。AWS EventBridgeは年フィールドを含む6フィールドの変種を使用します。L(最終)、W(最も近い平日)、#(第n回)文字はQuartz互換システムでサポートされている拡張ですが、POSIX cronではサポートされていません。

適切な時間ツールの選び方

各時間ツールはそれぞれ異なるタスクを担っており、4つのツールを1つのワークフローで組み合わせることもできます。ログ、APIレスポンス、データベースのカラムで生のエポック値に遭遇したときはタイムスタンプコンバーターを使用してください。Cronツールは組み合わせて使うと効果的です。マニフェストや設定ファイルにスケジュールをコミットする前に、ジェネレータで式を構築し、パーサーで次回実行時刻をプレビューし、バリデーターで構文を確認してください。

  1. 1
    次の目的の場合 Unixタイムスタンプを読みやすい日付に変換する、またはその逆タイムスタンプコンバーター
  2. 2
    次の目的の場合 既存のCron式が何を意味するか理解し、次回実行時刻を確認するCron式パーサー
  3. 3
    次の目的の場合 ビジュアルインターフェースを使って新しいCron式をゼロから構築するCron式ジェネレータ
  4. 4
    次の目的の場合 Cron式の構文が有効かどうか確認し、各フィールドを検査するCron式バリデーター

完全なCronワークフローとして:ジェネレータで式を構築し、パーサーで次回実行時刻をプレビューし、マニフェストまたはcrontabにコミットする前にバリデーターで構文を検証してください。APIやデータベースのタイムスタンプをデバッグする場合、タイムスタンプコンバーターは秒・ミリ秒両方のUnixタイムスタンプを処理し、ISO 8601、RFC 2822、ロケール形式の日付を出力します。タイムスタンプコンバーターはJWT検査にも役立ちます:JSON Web Tokenのexpクレーム(有効期限)とiatクレーム(発行時刻)はUnix秒のタイムスタンプであり、どちらの値もコンバーターに貼り付けることで、コードを書かずに正確な発行時刻や有効期限を確認できます。

よくある質問

Unixタイムスタンプとは何ですか?
Unixタイムスタンプは、Unixエポックと呼ばれる1970-01-01 00:00:00 UTCから経過した秒数(またはシステムによってはミリ秒数)です。タイムゾーンに依存しないため、同じタイムスタンプは世界中のどこでも同じ絶対的な瞬間を指します。JavaScriptはミリ秒タイムスタンプ(Date.now())を使用しますが、ほとんどのUnixユーティリティやデータベースは秒を使用します。
Cron式とは何ですか?
Cron式は、繰り返しスケジュールを定義するスペース区切りの5フィールドからなる文字列です。フィールドは分、時、日(月内)、月、曜日です。この形式はUnix Version 7(1979年)で導入され、現在はcrontab、systemdタイマー、Kubernetes CronJob、GitHub Actions、AWS EventBridge、その他多くのスケジューラーで使用されています。各フィールドは単一値(5)、範囲(1-5)、リスト(1,3,5)、ステップ値(*/15)、ワイルドカード(*)を受け付けます。例えば30 9 * * 1-5は平日のUTC午前9時30分を意味します。
秒タイムスタンプとミリ秒タイムスタンプを変換するにはどうすればよいですか?
秒タイムスタンプに1000を掛けるとミリ秒になります。ミリ秒タイムスタンプを1000で割り(結果を切り捨て)ると秒になります。秒タイムスタンプは通常10桁(例:1717200000)で、ミリ秒タイムスタンプは13桁(例:1717200000000)です。この2つを混同することは最もよくあるタイムスタンプのバグの一つです。
Cron式の*/5はどういう意味ですか?
*/5という構文は、指定フィールドの「5ごとの値」を意味します。分フィールドの*/5は、0、5、10、15、20、25、30、35、40、45、50、55分にジョブを実行します。ステップ演算子(/)は範囲にも使用できます。1-30/5は1から30の間で5分ごとを意味します。
タイムスタンプをUTCで保存すべき理由は何ですか?
UTCで保存することで、夏時間の切り替え、サーバーのタイムゾーンの不一致、リージョン間のデータ集計による曖昧さを排除できます。ローカル時刻への変換は表示層(UIまたはレポートレンダリング)でのみ行ってください。タイムスタンプをローカル時刻で保存すると、DSTの切り替え時に時刻のギャップと重複が生じます。例えば午前2時30分が存在しなかったり(春の時計を進める)、2回存在したり(秋の時計を戻す)します。UTCにはこのような切り替えがありません。このアプローチは分散システムの標準的な慣行であり、W3Cの日付・時刻フォーマットのノートでも推奨されています。
ISO 8601とは何ですか?
ISO 8601は日付と時刻の文字列表現の国際標準です。最も一般的な形式はYYYY-MM-DDTHH:MM:SS.sssZで、ZサフィックスはUTCを意味します。ISO 8601文字列は辞書順ソートで時系列順になるため、ログファイル、データベースのインデックス、APIレスポンスで実用的です。
Cron式は毎秒実行できますか?
標準の5フィールドcronはサブミニット(1分未満)のスケジューリングをサポートしていません。最小間隔は1分に1回(分フィールドに*を使用)です。Spring の@ScheduledやQuartzなど一部のシステムは秒単位実行を可能にする6番目の秒フィールドを追加しています。Kubernetes CronJobとcrontabは秒をサポートしていません。
2038年問題とは何ですか?
Unixタイムスタンプを32ビット符号付き整数として保存するシステムは、2038-01-19の03:14:07 UTCにオーバーフローします。32ビット符号付き整数の最大値は2,147,483,647で、その瞬間に相当します。オーバーフロー後、カウンターは1901年12月の日付を表す大きな負の数にラップします。JavaScriptなどのモダンな64ビットシステムおよび言語(Python 3、Go、Rust)は影響を受けません。レガシーの組み込みデバイス、ext3ファイルシステムのタイムスタンプ、古いMySQLのTIMESTAMPカラム、一部のバイナリプロトコルは引き続きリスクがあります。