架空の暦と改名の時間線

古い名前を直す前に、日付をそろえる

改名より後の手紙に以前の名があっても、すぐに表記ミスとは限りません。二つの文書が別の暦を使い、見かけの日付が同じ順序を表していないことがあります。一方で、本当に後で書かれた手紙、古い挨拶の引用、本人の選択を意図的に拒む呼び方もあり得ます。それらは別の創作上の判断です。この作業台は日付の計算を明示し、人物にとって重要な改名の場面を都合よく動かさずに検討するためのものです。

対象は作者が規則を決めた周期的な暦です。各年の月と日数、共通の日に対する起点、日付付きの改名と使用を入力します。異なる暦の記録を共通日の上に置き、選んだ暦へ変換し、名前の使用をその順序で照合します。同日と指定した二つの日付も確認できます。実在の暦の再現、歴史的な年代の確定、元号や時差の自動解釈ではありません。

創作例：衣装の荷札を残すか

衣装のラックを開けたまま、新しい一座が挨拶の稽古をしていた。順番が来るとLioは「この公演では、私のものにはKestと書いて」と言った。衣装係は新しい小包の宛名を書き直した。新しい文字を書くのは簡単だったが、既に服に縫った札まで全て変えるべきかは、まだ決まっていなかった。

公開稽古には港の暦を使い、山道の向こうの修理工房は尾根の暦で請求を付けていた。戻ってきたコートにはKest宛ての手紙があり、写しには稽古と同じ日という注記があった。一方、港側の稽古メモは改名の挨拶の後なのにLioと呼んでいる。衣装係がラックのLioを全て消そうとすると、Kestはまず日付を見たいと答えた。

港暦2年Dryの5日は共通日64になる。尾根暦1年Restの5日も同じ日で、Restの6日はその翌日だ。修理工房の手紙は実際には翌日の記録だった。共通日を64と写した注記は直す必要があるが、Kestという宛名は改名後の指定に合っている。港のメモは別だ。同じ共通日64でも、作者の順序では改名より後にLioを使っていた。

しかし、計算だけで場面の結論は決まらなかった。そのメモは、Kestが今回も残したいと言った以前の登場台詞を、仲間が稽古中に書いたものだった。Kestは現在の荷物の宛先を直し、引用した舞台小道具の札は残してほしいと頼む。「一つは今の仕事をどこへ届けるか、もう一つはこの公演がどこから始まったかを示すの」と言い、衣装係は消去ではなく制作メモを加えた。

古い駅の記録にもKestの名があった。ただし、その暦の初日が共通日のどこに当たるかは不明だった。一つの同日対応を採用すれば起点は60になる。Kestはその対応を確認するまで、公演の確定した年表に入れないことにした。役立つ日付の可能性と、確認できた日付は別だった。

これは独自の創作例です。Kestには本作で本人が選ぶ公の表記という役割を与えています。実在の語源、国籍、役者の経歴の説明ではありません。現在の宛名を全てLioのままにすれば、選んだ名が制作の記録に反映されません。過去の引用まで全てKestへ置き換えれば、本人が残すと決めた関係を失います。日付の変換は、どちらの選択も自動で決めません。

暦の名前より先に規則を定義する

各暦にはid、表示用のlabel、epochDay、周期の年を並べたcycleを設定します。epochDayは、その暦の1年目、最初の月の1日に対応する共通日の整数です。0は作者が指定した座標であり、世界全体の普遍的な歴史の始まりではありません。nullはその対応が不明という意味です。起点の座標は負にもできますが、入力する暦年は1〜10000です。0年や紀元の切り替えは扱いません。

周期の各年には月を読む順に並べ、正確なID、表示名、整数の日数を指定します。その周期全体が繰り返されます。初期例の港暦は40日の年と、5日のTurnを含む45日の年を交互に使います。尾根暦は毎年60日です。計算を追いやすいように作った小さな架空の制度で、実在の共同体の暦を短く説明したものではありません。

全ての暦で日境界を一つと仮定します。時差、日没の観測、欠けた日、時刻の端数、天文現象からの復元は範囲外です。その違いが筋書きに必要なら、整数日の変換だけで足りたことにせず、適した時間線を別に設計してください。暦の表示名を変えても、入力していない規則は追加されません。

最初の一日を二重に数えない

内部の相対日は、最初の月の1日を0にします。完了した周期、今回の周期内で前にある年、前の月、対象の日より前の日数を足し、最後にepochDayを加えます。初日が経過日数の一日として余分に増えないための規約です。初日の番号を1と表示することと、初日までに何日経過したかは分けて考えます。

港暦2年Dryの5日なら、前の年の40日、同じ年のFloodの20日、Dryの前の4日を足し、相対日は64です。港暦の起点が0なので、共通日も64になります。尾根暦1年Restの5日は、Watchの30日と前の4日で相対日34です。起点の30を加えると共通日64になり、二つの指定が一致します。

港暦3年の初日は40と45を足した85です。Turnを5日から9日へ変えると、3年の初日は89へ移ります。一方、Turnより前の改名は64のままです。重要な規則の変更は、その規則を通過した後の日に効きます。全ての記録を無関係に振り直したり、通常年に存在しない月を補ったりしません。

改名の記録と名前の使用を分ける

人物は固定したID、作業用のname、開始前のinitialFormを持ちます。initialFormは入力した全ての項目より前に有効な表記で、nullなら不明です。作業用ラベルは編集者が人物を見分けるためのもので、それ自体を改名とは扱いません。同じ表示名でもIDが違う人物を統合しません。

adoptは指定した位置で正確な表記を採用し、useはその位置の有効な表記と使用文字列を比べます。先に共通日で並べ、同じ人物の同じ日では明示したorderを使います。初期例の改名は0、old-addressは1です。改名を2へ変えると、old-addressは改名より前になり、Lioは開始前の表記と一致します。入力表を貼った順が、場面の順序を決めるわけではありません。

同じ人物、同じ日、同じorderが二つあれば、どちらを先とするか決めずに拒否します。別人同士の名を照合するために、不要な全員共通の順序を強制することはありません。比較は完全一致で、Kestとkestも違います。略称の同等性、呼称の許可、敬意、人物の感情を文字の違いから推定しません。

不明な過去を、確定した後日へ置かない

古い駅の項目は有効な現地の日付を持ち、相対日は5です。しかし起点がnullなので、共通日もnullです。表記と日付を残し、後から根拠を確認できる記録として使えます。都合のよい0日を与えて確定した年表へ入れません。表では共通日が分かる行の後に分けて表示しますが、物語上で必ず後に起きたと主張する並べ方ではありません。

同じ人物に起点不明の暦での改名がある場合、この版は、その人物の使用の一致を保守的に確認不能とします。使用自身の共通日が分かっていても、その不明な改名がどこに入るかで有効な表記が変わり得るためです。可能な起点を全て列挙したり、表で後にあるから以前の使用は安全と認定したりしません。

開始前の表記の不明と、暦の起点の不明も別です。日付が分かる改名でその後の表記を確定できても、以前の名を復元したことにはなりません。足りないのが起点か、以前の表記か、移行の指定かを区別します。全てのnullを便利な値で埋めれば表はきれいになりますが、作品が実際に持つ不確かさを消してしまいます。

同日対応は、採用前に確かめる

synchronismsは二つの日付を同じ共通日とする作者の主張です。両方の起点が分かれば等しいかを調べます。一方だけが分かれば、その共通日から不明な暦の相対日を引いて起点案を示します。初期のold-bridgeは64から4を引き、60を提案します。同じ出来事を指すという根拠自体を、ツールが外部で調べたわけではありません。

提案は自動適用しません。なぜその二日を同じとみなすかを確認し、採用するならcalendarsのepochDayを明示的に編集して再計算します。old-logは共通日65に置かれ、Kestという使用を改名と比べられるようになります。同じ日にある別の使用とはorderを分けてあるため、区別したまま年表へ入ります。

別の対応が同じ暦に61を提案するなら、60と61を矛盾した候補として残します。平均を取らず、警告が少なくなる方を選びません。起点不明の二暦をつないだだけでも、共通の起点は得られません。この版は不明な対応を連鎖して自動的に埋めないので、使う根拠を明示してから判断してください。

変換できたことと、台詞の意図は別

変換先のIDを選ぶと、共通日が分かる記録をその暦の日付へ戻します。変換先の起点が不明なら日付は得られません。1年目より前や10000年目より後は対象範囲外で、負の年を創作しません。変換先が得られなくても、元の日付と確認できた共通日は残ります。

claimDayは任意の共通日に関する主張です。尾根の手紙の64という入力は、その日付から求まる65と矛盾します。しかしKestという表記は有効な名に一致します。写した共通日を直すことと、宛名を変えることは違う修正です。二つを分けることで、一方の問題を直しただけで全て解決したように見せません。

衣装の例では、以前の表記を引用に意図して残せます。その判断は制作素材の横に記録してください。計算上の完全一致の違いは、その場合も表示します。ツールは自動で例外を許可せず、台詞を書き直さず、引用の良し悪しも決めません。全ての名前が交換可能なら、今の承認と自分で残した過去の痕跡を区別する場面の意味が失われます。

次の改稿へ根拠を持っていく

コピーには表記だけでなく日付と照合の説明が入ります。保存する場合も人物と項目の範囲を保持し、同じKestを使う別の記録を一つへまとめません。比較で、宛先、日付の注記、衣装の札のどこに対応が必要かを検討できます。結果の書き出しと、暦・命名の非公開の引き渡しには未解決の対応も含まれます。共有前には実際の内容と相手が知ってよい範囲を確認してください。

起点を採用する前にプロジェクトを保存か書き出ししておきます。復元は結果にある名前から推測するのでなく、保存した暦と項目の入力を戻します。規則の変更は後の多くの記録を動かし得るので、変換を再確認します。実在の暦の研究は別の根拠確認として扱ってください。この作業台が提供するのは、再現できる架空の規約と、何を修正するかを明確にする材料です。

実在の暦の名前を入力すれば規則が分かりますか

labelから暦の知識を補いません。周期の年、月の日数、起点を明示します。0年、紀元の切り替え、時差、天文現象からの復元は扱いません。実在の日付には適切な調査と別の方法を使ってください。

起点の提案で暦を自動修正しますか

同日とする主張から求める未適用の案です。矛盾する候補も残します。根拠を確認し、epochDayを明示的に編集して再計算します。不明同士の対応を連鎖して起点を推定しません。

使用の日付が既知なのに確認不能なのはなぜですか

その人物に起点不明の改名があると、有効な表記が変わり得ます。不明な改名を必ず後と扱わず、使用の判定を保守的に保留します。開始前の表記が不明な場合も、以前の使用は照合できないことがあります。

以前の表記の不一致は台詞の修正を意味しますか

入力した移行に対する完全一致を調べるもので、必ず修正すべきとの判断ではありません。引用、拒否、過去の参照を意図することもできます。その編集理由は別に記録し、計算で感情を推定したり例外を承認したりしません。