EPUBの発行日は、ファイルの作成日や最終更新時刻とは別の情報です。epub dateを設定するときは、作品として示す発行日、EPUBを生成した時刻、dcterms:modifiedを別欄にします。同じ日付が並ぶ場合も、役割を書いておくと再版時に間違えません。
設定応答と生成OPFの日付が異なった
検証では単巻の発行日に2026-12-17を設定し、CLIの返値でその日付を再取得しました。しかし、固定時刻で生成したEPUBのcontent.opfにあるdc:dateは2026-09-03T09:00:00+09:00でした。つまり、ワークスペース設定の保存と、出力メタデータへの反映は別に判定すべきです。
この状態を「発行日設定が完了」と書くと、実際の生成物と食い違います。回復では、ウィザードの保存値を再確認した上で、生成処理がどの日付をdc:dateへ書くかを切り分けます。作品日付と生成時刻のどちらが正本かを決めるまで、完了扱いにしません。
生成EPUB自体は画像4、spine8、nav4、NCX4でvalid=trueでした。ただし、構造が有効でもタイトルの約束である発行日が意図と異なるため、日付の合格にはなりません。完了条件は、保存値とOPFの実値が同じ役割と日付を示すことです。
入力した日付とOPFに見つかった日付を分ける
発行日2026-08-24は作品情報の応答で保持されましたが、今回のOPF検索では同じ文字列を確認できませんでした。これは日付入力の失敗と断定する結果ではなく、「OPFへの表現を未確認」とする結果です。dc:date、更新日時、独自メタデータなど候補要素を仕様と実装から確認し、どの値を販売用の発行日とするか決めます。
再試験では日付だけを一日変え、二つのOPF差分を取ると収録位置を特定しやすくなります。タイトルや出版社を同時に変えないのが要点です。差分に日付相当がなければ未対応として引き渡し記録へ残し、設定画面の表示をパッケージ収録の証拠に置き換えません。
日付差分だけを作る対照試験
一冊目へ2026-08-24、二冊目へ2026-08-25を設定し、ほかの入力を同一にすれば、生成物のどこへ日付差が現れるか調べられます。ZIP内の全ファイルについてハッシュを比較し、変化したファイルだけを開きます。OPFに差がなければ、別ファイルや設定内だけに保持される可能性を検討します。
差が見つかっても、その要素が発行日を意味するかを仕様で確認します。更新日時と発行日を取り違えると、再出力のたびに値が変わるからです。dc:dateなど名前だけで即断せず、属性や役割も読みます。
今回の一冊だけの検索では、OPF収録を証明できませんでした。未確認を明示したまま追加試験へ進むことが、設定応答を出力証拠にすり替えない回復策です。
販売日と更新日を取り違えない記録
作品には初版の発行日、改訂版の発行日、ファイルの生成日時が併存します。入力カードへ三つの欄を作り、今回設定した2026-08-24がどの役割かを明示します。OPFで日付らしい値を見つけても、役割を確認せず発行日として採用しません。
タイムゾーン付き日時や日付だけの値は表現も異なります。比較時は勝手に同じ形式へ丸めず、原文値と解釈値を二列で残します。販売先が要求する形式が別なら、ローカルパッケージの検証後に変換規則を適用します。
日付がOPFに見つからない版を公開候補へ混ぜないため、ファイル名にdate-unverifiedなどの保留印を付けます。追加試験で収録位置を確認し、同じ生成物のハッシュであることを確かめてから保留を外します。
不正日付がexit 0になったところから始める
追加標本で2026-02-30をepub volume set --dry-runへ渡すと終了コードは0でした。つまり日付らしい形式を受け付けた応答だけでは、実在する暦日かどうかを保証できません。カレンダーで検算し、回復値2026-08-17へ置き換えて保存しました。volume listの再読込みではそのISO日付が保持されていました。
奥付ではAugust 17, 2026を確認した
英語・横書き・版1.0の1章標本を固定時刻で決定的に出力しました。EPUBはvalid=trueで、展開したOEBPS/Text/colophon.xhtmlにはAugust 17, 2026 eBook ver 1.0 publishedが1件あります。Page 5へ入れた値が読者向け奥付へ届いたことは、このファイルで確認できます。
OPFのdc:dateは出力時刻だった
同じEPUBのOEBPS/content.opfを読むと、<dc:date>2026-09-03T09:00:00+09:00</dc:date>でした。指定した2026-08-17を含むOPFは0件です。この実測版1.4.0 build 23では、発行日設定をOPFのdc:dateへそのまま運ぶとは証明できません。むしろ固定出力時刻が入るという差を残します。
Page 5の画面操作は未実測とする
CLIはPage 5の背後にある巻設定を変更できますが、日付ピッカー自体は描画しません。選択色やボタンの反応を見たとは書きません。画面を使う場合も、保存後のvolume list、奥付、OPFという三地点を読み、表示だけで完了にしない方針は同じです。
この結果から、奥付の日付を設定する場所としてPage 5を案内できます。一方、配信先がOPF dc:dateに発行日を要求するなら、この版の出力をそのまま合格にできません。パッケージを検査し、仕様に沿う別工程または製品修正を選び、再生成後に再確認します。発行日と生成日時を同じ意味として扱わないことが結論です。
日付の受け渡し票には、入力ISO日付、暦検算、保存状態、奥付表示、OPFのdc:date、出力固定時刻を別々に置きます。今回なら2026-08-17と2026-09-03T09:00:00+09:00が並び、差が意図どおり見えます。どちらか一方を「EPUBの日付」と略さないことが、後の配信審査で役立ちます。