出生資料の確認

「その日付は何の暦か」から確かめます

家族が伝えてきた日付と書類の日付を比べる前に、使われている暦を確認します。西暦の数字に見えても、元の話が農暦の日付なら別の処理が必要です。中国の農暦を扱う場合は閏月の有無も確認し、分からないまま通常月として換算しないようにします。

香港天文台の西暦・農暦対照表は、年ごとに日付を確かめる資料の一つです。備考には、遠い時期の朔や節気が真夜中に近い場合の境界上の不確かさも示されています。日付の対照資料であり、世界中の地域の時計制度をすべて示す資料ではありません。

元の表記を消さず、処理を別欄に書きます

元の時計時刻と、時差などを適用した時刻を同じ欄へ上書きすると、次の入力で二重に補正するおそれがあります。原資料はそのまま残し、どんな前提で何を換算したかを別に記します。訂正できる形を保つことが、見かけの細かさより大切です。

時刻が「だいたい」としか分からなければ、支持できる幅を残します。分や秒を入力できる画面でも、資料の精度が増えたわけではありません。仮の値を使う場合は未確認のまま扱い、何度も使ったから確定値になったと考えないようにします。

元の図を開いて拡大する

BaZiFlowオリジナル資料図。項目の関係だけを示し、個人の出生情報は含みません。

同じ地名でも、場所の身分を確認します

国や地域、必要な上位区分を添えて、同名や旧名の取り違えを防ぎます。県やCountyなどの語は、国によって行政階層が同じとは限りません。名称の末尾だけで粒度を決めず、その地域で何を指すかを確かめます。

市級・県級の地域として特定できる入力を、無理により細かな地点へ変える必要はありません。また、地域そのものをその首府や役所所在地へ黙って置き換えることも避けます。地名のラベルと座標の出典が同じ対象を指しているかを確認します。具体的な場所が分かるときだけ、その場所として扱います。

まだ国や大きな区域までしか分からないなら、不足を残します。計算に不要な番地や身分証番号、家族の情報を集めても、時差や暦の問題は解決しません。教えるために共有するときも、本人が分かる情報は不要で、確認したい設定だけを示せます。

時差は、その場所のその日付に対応します

IANAの時間帯データベースは、代表的な地点の地方時の歴史を扱い、境界、UTCとの差、夏時間規則の変更に応じて更新されます。現在の時差を過去の全日付へ当てはめないために、地域の時間帯と利用した資料の版を記録します。

出生資料を使わない算術例では、現地10:00がUTC+08:00と確認済みなら、UTCは02:00です。10から8を引いた値ですが、適用する差がすでに分かっていることが前提です。地名だけから推測したわけではありません。太陽時に関する処理は別の規則なので、時差と混ぜて再度差し引かないようにします。

ツールが元の時計時刻を求めて自動換算するなら、先に手で補正した時刻を渡すと処理が重なる可能性があります。欄や設定の意味を確認し、分からないときは入力と設定を保存します。違いの調べ方は同じ入力で結果が異なる場合で扱います。

後で分かったことを、修正として残します

家族の記憶と書類が異なる場合、先に両方を保存し、由来と精確さを確認します。新しい証拠が得られて範囲を狭めるなら、何を理由にどの項目を変えたかを記します。換算を直したことと、原書類が間違っていたことも区別します。

複数の解釈から一番自分らしいものを選ぶことは、元の記録の確認とは違います。唯一の値が得られなければ候補範囲を残せます。出生時刻の不確かさでは、その範囲でどの項目が変わるかを調べます。

確認済み、候補、未確認の区別があれば、次の読み手は作業を引き継げます。全欄を埋めることより、元の資料と処理がたどれることを、確認の成果として残してください。

1. 1

   二つの値を保存する

   原資料は現地10:00、処理欄は確認済み+08:00とUTC02:00を記します。

2. 2

   二重処理を試算する

   現地時刻を求める欄へ02:00を入れて再度8時間引くと、前日の18:00という誤った結果になります。

3. 3

   入力の種類を直す

   現地時計を求められたら10:00を渡し、時差と換算結果は別の処理欄へ残します。