日付フォーマット指定子チートシート (dayjs / strftime)

日付フォーマット文字列が暗示する業務コンテキスト

「%Y/%m/%d %H:%M:%S」というパターンを検索しているとき、その人が何かを開発していることは明らかです。もう少し踏み込めば、どの言語スタック (Python / Ruby / PHP) を使っていて、どのような形式の出力を必要としているか — つまり担当業務の輪郭まで読み取れます。オンラインの日付フォーマット検索ツールは、クエリをサーバーに飛ばすことで「誰がいつ、どのフォーマットをどれだけ頻繁に調べているか」という行動ログを蓄積します。個々のクエリは地味でも、継続的なパターンは業務リズムや担当プロジェクトを推定する素材になります。

SaaS 系のオンラインツールはリリースサイクルや機能追加の資金調達のため、広告ターゲティングデータを活用することがあります。入力したフォーマット文字列から「バックエンドエンジニアが ISO 8601 形式の出力を必要としている」と分類されれば、それは広告プラットフォームに渡される属性情報の一部になりえます。

開発リズムを外部に観測させないために

プログラミング中にドキュメントを引くのは自然な行為ですが、その頻度や内容が外部サーバーに送信され続けると、チームの作業ペースや未公開機能の方向性がじわじわと漏れていきます。「YYYY-MM-DDTHH:mm:ssZ の形式の RFC 3339 出力が必要」というクエリは、どのシステムと何の仕様に合わせようとしているかの情報を含みます。日々の参照先をブラウザ内完結のツールに変えることは、開発ログを外部に渡さない小さな習慣です。

Date API と文字列置換だけでブラウザ内に閉じる仕組み

このツールはブラウザ標準の Date オブジェクトを使って現在時刻 (またはユーザーが入力した基準日時) を取得し、dayjs / Moment.js 形式と strftime 形式の 2 系統のトークンを JavaScript の文字列置換で展開します。外部 API の呼び出しはなく、入力したパターン文字列はブラウザのメモリ内で処理されたままです。タイムゾーンはブラウザのローカル設定をそのまま使い、UTC オフセットも Date.prototype.getTimezoneOffset() から直接取得します。

DevTools の Network タブを開いた状態でパターンを入力しても、ページ読み込み以降にリクエストが発生しないことをリアルタイムで確認できます。ソースコードは GitHub で公開しているので、文字列置換のロジックを第三者が監査することも可能です。

プリセットをチェックリストとして使う

ISO 8601 / RFC 3339 / RFC 2822 / 日本式 / US 式 / ログ用など 10 プリセットを用意しているのは、「仕様書の形式と自分の出力がずれていないか」を素早く確認するためです。ログ出力のフォーマットを統一したい、API レスポンスのタイムスタンプ形式を外部仕様に合わせたい、といった局面で基準となるパターンを手元に持っておくと、実装前のミスを事前に防げます。

dayjs トークンと strftime トークンの設計思想の違い

dayjs / Moment.js 系のトークンは「YYYY は 4 桁年・MM は 2 桁月」のように 文字を重ねて桁数を表現 する設計で、桁を増やせばゼロパディングが効きます。一方 strftime (C 言語の <time.h> 由来、Python datetime.strftime / PHP date / Ruby Time#strftime で使われる) は %Y %m %d のように % プレフィックス + 1 文字 で表現します。本ツールはこの 2 系統を独立した文字列置換パスとして実装し、Mode 切替で安全に切り替えます。

最も事故が多いのは大文字小文字の意味です。dayjs では MM が月・mm が分・DD が日付・dd が曜日名と意味がまったく違い、MM/DD を mm/dd と書くと「月/日」が「分/秒未満」になります。strftime も %M が分・%m が月で逆に間違えやすく、%Y (4 桁年) と %y (2 桁年) も混同しがちです。プリセットを採用すれば仕様書由来の正しい組み合わせがそのまま入るため、トークンの大文字小文字を 1 つ間違える事故を避けられます。

タイムゾーン・UTC オフセット・地域フォーマットの落とし穴

ISO 8601 と RFC 3339 はどちらも YYYY-MM-DDTHH:mm:ssZ 形式を採用していますが、RFC 3339 の方が一部の表記 (時間と分の間のコロン省略など) を禁止しており、API のタイムスタンプ仕様としてはより厳密です。本ツールは Date.prototype.getTimezoneOffset() でブラウザのローカルタイムゾーンを使うため、Z (UTC) を出力したい場合は事前に基準日時を UTC で指定するか、出力後に +09:00 形式のオフセットを Z に置換する必要があります。

ロケール依存も無視できない要素です。MMMM (月名)・dddd (曜日名) などのトークンは、英語環境では January Monday、日本語ロケールでは 1月 月曜日 を返します。本ツールはブラウザの Intl.DateTimeFormat を一部で利用するため、出力が navigator.language に影響されます。複数地域でログ収集する場合は、ロケール非依存の数値表現 (YYYY-MM-DD) を採用するのが安全です。整形対象の値を unix epoch 秒として扱いたい場合は unix-timestamp で Date ↔ epoch ↔ ISO の往復確認ができ、ISO 8601 が示す週番号 (YYYY-Www) の境界を見たいときは iso-week で年と週をマトリクスで確認できます。