BaZi の規約
BaZi計算機に生年月日時刻を一度入力すると、2つの異なる命式が得られることがあります。時には異なる日主、つまりすべての読みの基礎となる漢字が得られることもあります。これはどちらかの間違いではありません。それぞれの命式の背後には4つの慣習があり、それぞれに歴史があり、計算機はそれらを暗黙的に、かつ異なる方法で適用しています。
以下に、これら4つの慣習に対する当社の方針を説明します。これらは各レスポンスのdisclaimerフィールドで宣言されており、その変更はリファクタリングではなく、破壊的変更となります。
1. 年の始まりはどこか：立春か旧正月か
Section titled “1. 年の始まりはどこか：立春か旧正月か”当社の方針：立春（りっしゅん）、正確な瞬間です。
BaZiは、太陰太陽暦の中にある太陽暦システムです。月の柱は二十四節気、つまり月の満ち欠けではなく太陽の位置に結びついており、年も同じ論理に従います。年が切り替わるのは立春、およそ2月4日です。旧正月は別のもので、太陰暦の最初の新月であり、1月末から2月末の間を移動します。
この期間に生まれた場合、あるルールではある動物に属し、別のルールでは別の動物に属します。どちらのルールも有効です。当社では立春を採用しており、その瞬間は「2月4日」という日付からではなく、暦表から取得されます。
2. 日の始まりはどこか：23:00か真夜中か
Section titled “2. 日の始まりはどこか：23:00か真夜中か”当社の方針：出生地の時計で23:00です。
伝統的な1日は十二時辰であり、その最初の「子の刻」は23:00から01:00までです。他のすべての時辰は1つの暦日に収まります。子の刻は真夜中をまたいでおり、この唯一の構造的事実からすべての論争が生まれます。もし子の刻が日の始まりであるならば、23:30の誕生はすでに翌日に属することになります。
これは日主を変える軸です。日の柱を移動させることは、命式を明確にするのではなく、命式を置き換えることになります。
そのため、別の読み方が隠されることはありません。各命式エンドポイントはdayBoundary: "23:00" | "midnight"（デフォルトは23:00）を受け入れ、23:00の誕生はalternateDayとともに返されます。これは、あなたが選択しなかったルールに基づく日の柱と日主です。遅い子の刻は、いずれにせよ翌日から天干を取るため、時柱は両方で同じです。00:00から00:59までは、すべての流派が日について同意しているため、そこに代替はありません。
3. 時刻は出生地の経度に合わせて修正されるか
Section titled “3. 時刻は出生地の経度に合わせて修正されるか”当社の方針：リクエストに応じて、日と時のみ修正します。
このシステムの歴史の大部分において、この問題は発生しませんでした。現地時刻が太陽時そのものだったからです。タイムゾーンは鉄道時代に発明されたものであり、国が単一の時計で生活するようになると、その時計は単一の子午線でのみ太陽と一致します。中国は極端な例で、経度60度に対して1つのタイムゾーンしかありません。そのため、カシュガルでの誕生は、北京時間で太陽の正午からほぼ3時間ずれています。
curl -X POST https://api.astroway.info/v1/chinese/true-solar-time \ -H "X-Api-Key: aw_live_..." \ -H "Content-Type: application/json" \ -d '{ "date": "1995-06-15", "time": "09:20:00", "timezoneOffset": 8, "longitude": 75.9 }'4. 夏時間（サマータイム）の扱いについて
Section titled “4. 夏時間（サマータイム）の扱いについて”当社の方針：呼び出し元のみがそれを知っています。
timezoneOffsetフィールドは、誕生時に実際に時計が示していたオフセットです。1988年の北京での誕生はUTC+8ではなくUTC+9に従っていました。なぜなら、中国は1986年から1991年まで夏時間を実施していたからです。当社の側では、日付だけからこれを算術的に復元することはできないため、推測はしません。
5. レスポンスが自身について語ること
Section titled “5. レスポンスが自身について語ること”/v1/bazi/chartの各命式エンドポイント、およびday-master、ten-gods、luck-pillars、yearly、monthlyといった分析エンドポイントは、conventionsオブジェクトを返します。これには、年と月の境界（lichun、jie）、使用されたdayBoundary、真太陽時が適用されたかどうかとその分数、オフセット付きのタイムゾーン、夏時間が適用されたかどうか、そして誕生のグレゴリオ暦年における旧正月の情報が含まれます。timezone.assumed: trueは、タイムゾーンもオフセットも送信されず、境界が北京時間で解釈されたことを意味します。
時刻なしの日付は正午として解釈されます。立春または節がこの現地日に該当する場合、レスポンスは時刻に依存するため、boundaryInDayを追加します。これには、境界の種類、現地時刻、正午がどちら側に位置したか、そして両側の年柱と月柱が含まれます。
境界の瞬間そのもの、1900-2100年
Section titled “境界の瞬間そのもの、1900-2100年”年柱と月柱はそれぞれ立春と残りの11の節の瞬間に依存するため、これらの瞬間は当社のコードとは共通点のない2つの情報源と照合されています。1900年から2100年までの各年における、月を開く12の節気、つまり合計2,412の瞬間は、JPL Horizons (DE441) を通じて独立して、100分の1秒の精度で特定されました。当社の瞬間は、1950年から2025年までは4秒以内、1900年までは8秒以内でそれらと一致しています。2025年以降は、両者が地球の自転がどのようにドリフトするかを予測する必要があり、予測は徐々に乖離し、2100年には最大21秒の差が生じます。
UTC+8における同じ節気のデータは、香港天文台の1901-2100年の表と照合されました。2,400のうち2,398が一致しています。異なる2つのケース、1917年の大雪と1927年の白露は、真夜中から数分後に発生しており、Horizonsは当社のデータと一致しています。
外部データセットでの検証
Section titled “外部データセットでの検証”Jade Almanacは、これら4つの軸に基づいて特別に構築された13のプローブに対する8つの実装の比較をCC0ライセンスで公開しています：jadealmanac.com/bazi-calculator/conventions。このデータセットは正確さではなく慣習を測定しており、そのこと自体を述べています。
当社は、POST /v1/bazi/four-pillarsをこれら13のプローブすべてに対して実行しました。結果はリポジトリ内のコマンドで再現可能であり、テストで固定されています。
| プローブ | 隔離対象 | 当社のレスポンス |
|---|---|---|
1985-02-10 | 年の境界 | 立春がすでに過ぎているため Yi-Chou |
1990-06-15 23:30 | 日の切り替わり | 日がすでに切り替わっているため Ren-Zi |
1988-02-04 23:00 | 立春と23:00の組み合わせ | Wu-Chen Jia-Yin Geng-Yin Bing-Zi |
1995-06-15 09:20 カシュガル | 真太陽時 | 修正なし Yi-Si、修正あり Gui-Mao |
当社が具体的に誰と一致しているかについて、正直な注記があります。データセットの公開元は、そのエンジンがtyme4tsと、同じ作者のlunar-javascriptに基づいていると述べています。したがって、表の上3行は1つの系統であり、3つの独立した意見ではありません。それらとは独立して、feng-shui-institute.orgが完全なカバレッジを持っており、真太陽時を適用した後、当社は彼らが修正を適用する3つのプローブすべてでそのレスポンスを再現しています。
当社と流派との間に残る唯一の真の相違点は、23:00での日の切り替わりです。