団塊世代の黄昏

1. 明治改暦の背景と断行理由

明治5年（1872年）末、明治政府は従来の太陰太陽暦（旧暦）を廃止し、太陽暦（グレゴリオ暦）を導入しました。欧米に合わせた近代化の一環という側面に加え、短期間で性急に断行された直接的な契機は明治政府の逼迫した財政事情と経費削減でした。

• 官吏への月給支給回数の削減：官吏への給与を月給制へ移行した直後でしたが、旧暦のままでは翌年の明治6年に閏月（閏6月）が発生し、年13回分の給与を支払う必要がありました。太陽暦へ移行して閏月をなくすことで、年12回の支給に抑えました。
• 明治5年12月分の給与カット：旧暦の明治5年12月2日の翌日を明治6年1月1日（新暦）としたため、明治5年12月は2日間しか存在しませんでした。政府はこの短さを理由に12月分の月給支給を取りやめ、明治5年の給料を実質11か月分で済ませました。
• 休業日の削減（労働日数の確保）：毎月「1と6のつく日」や節句・寒暑休暇など年間約4割に及んでいた従来の休業日を改め、日曜日を休日とする週休制を採用しました。年間休業日を約50日に減らし、生産性を高める狙いがありました。

2. 皇紀（神武天皇即位紀元）の成立と制度化

制度としての皇紀は、明治以前には存在せず、明治5年に初めて公式な紀年法として制定されました。

• 明治以前の紀年法との相違：江戸時代以前は「元号」と「干支」の組み合わせが基本であり、天皇ごとの在位年数を数えることはあっても、初代から通算して積算する紀年法は公私ともに使われていませんでした。
• 公式紀元としての制定：明治5年11月9日に改暦が布告されたわずか6日後の11月15日、太政官布告第342号により「太陽暦御頒行神武天皇御即位ヲ以テ紀元ト定メラル」と定められ、皇紀が公的な紀元となりました。

3. 「紀元前660年」の根拠と作為性

皇紀元年が西暦紀元前660年（60の倍数）とされた背景には、古代中国の予言思想である「辛酉革命（しんゆうかくめい）説」に基づく作為的な編年が存在します。

• 讖緯説（しんいせつ）と辛酉革命：干支の組み合わせで政変が起こるとする思想において、60年周期の「辛酉（かのとのとり）」の年は王朝交代などの大変革が起こる年とされました。
• 1260年（褶運）の周期：辛酉が21回巡る「60年 × 21回 ＝ 1260年」は「褶運（かいうん）」と呼ばれ、極めて重大な国家的変革（大革命）が起こる節目と位置づけられました。
• 推古天皇9年（西暦601年）からの逆算：『日本書紀』編纂時、聖徳太子が活躍した推古天皇9年（601年）が辛酉の年でした。この601年から大革命の周期である1260年分を遡って逆算した年（$601 – 1260 = -659$、歴史的表記で紀元前660年）を、初代天皇即位の辛酉年（皇紀元年）として位置づけました。

4. 西暦に対して皇紀を採用した明治政府の意図

西暦の導入と並行して皇紀を公式採用した背景には、国際協調（近代化）と国内向けナショナリズム（国体意識）を両立させる狙いがありました。

項目	明治政府の狙いと背景
キリスト教色の回避	西暦はキリスト生誕を起点とするため、キリスト教への反発や警戒感が残る国内の神道派・保守層へ配慮し、そのまま公用採用することを避けました。
国家正統性の対外誇示	西欧列強の通算紀元に対抗し、日本にも独自の長い歴史があることを示すため、「万世一系」の皇統を象徴する起点を用いました。
通算紀年の実務的確保	「一世一元の制」により元号が天皇一代ごとにリセットされる弱点を補い、長期的な歴史記述や統計管理に適した無期限の通算紀年を確保しました。

 

5. 実務面での融合：皇紀を用いた置閏法（うるう年の規則）

明治31年（1898年）の勅令第90号「閏年ニ關スル件」において、皇紀はグレゴリオ暦の正確な天文学的アルゴリズムを国内法に落とし込むための枠組みとして活用されました。

「神武天皇即位紀元年數ノ四ヲ以テ整除シ得ヘキ年ヲ閏年トス 但シ紀元年數ヨリ六百六十ヲ減シテ百ヲ以テ整除シ得ヘキモノノ中更ニ四ヲ以テ商ヲ整除シ得サル年ハ平年トス」

• グレゴリオ暦との整合：皇紀年数から660を引くと西暦年数と一致します。
• 仕組みの意義：条文上は皇紀を用いながら、「（皇紀−660）が100で割り切れ、かつ4で割り切れない年は平年」という規定にすることで、実質的にグレゴリオ暦の置閏ルール（明治33年／西暦1900年を平年とする規則など）を過不足なく機能させました。

これにより、表面上は天皇を中心とする日本の伝統的権威を守りつつ、実務上は近代西欧の暦法を正確に運用するという巧みな制度設計が実現しました。

Jypyter Lab（又は notebook）でJavaScrit を書いているのだが、他の自作のスクリプトをコールしたいような場合は、そのスクリプトも ipynb に記述しなけれならない不便さがある。
その解決策として、覚えたての import 文が使えるのではないかと考えて使用してみたが、

となってあえなく挫折。その理由を Gemini へ尋ねてみた。
「Jupyter Notebook の JavaScript（Node.js）カーネル（一般的に広く使われている IJavaScript など）では、セルの内部で静的な import 文をそのまま使用することは原則できない。」とのこと。
しかしながら「Node.js（IJavaScript）の代わりに Deno カーネル を導入すればモダンな JavaScript / TypeScript を記述し、標準の import 文が使えることが可能になる」とのこと。
Deno のインストールを以下に示す。
環境は、Windows11（wsl2 ではない）でPowershellから実行する。
ステップ1：Denoのインストール

ステップ2. インストールの確認
正常にインストールできたか確認するため、PowerShell を一度落として再起動し、以下のコマンドを入力する。

画面に deno 2.x.x といったバージョン情報が数行表示されれば成功。
ステップ3. Jupyter へのカーネル登録
すでに PC 内に Python（Jupyter Notebook や JupyterLab）Jupyter 環境がある状態で、以下のコマンドを実行する。

ステップ4. Jupyter への登録確認
Jupyter Notebook / JupyterLab を起動し、カーネル選択画面に「Deno」が表示されていれば成功！

補足事項

実際使用して、エラーとなった点について補足する。

• 相対パス記号を先頭に付ける（誤：module、正：./module)
• module.exports（CommonJS形式）はエラーになる。
  
  // ファイルの末尾などがこのような形式になっている module.exports = { ymdToMjd, mjdToYmd };

  1 2	// ファイルの末尾などがこのような形式になっている module.exports = { ymdToMjd, mjdToYmd };

  これを以下のようなコードに変更する。
  
  export function ymdToMjd(y, m, d) { ... } export function mjdToYmd(mjd) { ... }

  1 2	export function ymdToMjd(y, m, d) { ... } export function mjdToYmd(mjd) { ... }

  このように関数の前に ’export’ をつけることが必要。

Mathjaxの設定

WordPressで手っ取り早くLatex数式を使用したい場合は、プラグイン「MathJax-LaTeX」をインストールすればよいのだが、CDNから最新版のものを使用したいような場合の設定方法について説明する。
CDNを使用する場合、新たなプラグインをインストールし、WordPressテーマのヘッダにスクリプトを設定するため、不慣れな方は「MathJax-LaTeX」を使用する方が無難と思われる。
CDNの設定手順を以下に示す。

• 1. プラグインの確認とインストール
  • WordPress管理画面の「プラグイン」>「新規追加」を開く。
  • 検索窓に「WPCode」と入力する。
  • WPCode Lite を「今すぐインストール」して「有効化」する。
• 2. ヘッダー（Header）へのコード挿入
  • 有効化すると、管理画面の左メニューに「コード スニペット」という項目が追加される。
  • 「コード スニペット」>「ヘッダーとフッター」 を選択する。
  • 画面上部にある 「ヘッダー」 のテキストエリアに、読み込ませたいMathjaxのCDNコードを貼り付ける。貼り付けるコードは例を参照
  • 画面右上にある 「変更を保存」 ボタンをクリックする。

【例】Mathjax CDN

Mathjax 記法

• インライン記法
  数式を \(…..\) で囲む When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are

  1 2 3 4 5

  数式を \(…..\) で囲む   When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are

  When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are

• ブロック記法
  数式を\[と\]で囲む

  1	数式を\[と\]で囲む

  数式を\[と\]で囲む \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}\] または \[x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\]

  1 2 3 4 5 6 7

  数式を\[と\]で囲む   \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}\] または \[x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\]

  \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}\] または
  \[x = \frac{-b \pm \sqrt{b^2 – 4ac}}{2a}\]

互換性

CDNだけをヘッダに設定した場合、過去に\$（インライン）、\$\$（ブロック）使用していた数式が変換されなくなります。
この問題を解消するためには、前段で設定した Script タグの下に、次のコードを貼り付けます。

これにより、以前のコードそのままに数式を表示させることができます。
【使用例】

$$x = \frac{-b \pm \sqrt{b^2 – 4ac}}{2a}$$

基本的には、AdSenseの「共通コード（スクリプト）」をWordPressのタグ内に1度だけ貼り付けるだけで、AIが記事内の最適な場所に広告を自動挿入するようになります。
WordPressに設定する3つの代表的な方法を紹介します。ご自身のスキルに合わせて選んでください。

---

方法1：テーマの標準機能を使う

多くのWordPressテーマ（Cocoon、SWELL、Lightningなど）には、最初からAdSenseコードを貼り付ける専用の枠が用意されています。プラグインを増やしたくない場合に最適です。

1. WordPress管理画面から [外観] ＞ [カスタマイズ]（またはテーマ固有の設定メニュー）を開く。
2. 「アクセス解析」 や 「高度な設定」、「ヘッドタグ挿入」 といった項目を探す。
3. AdSenseの管理画面からコピーした「自動広告コード」を貼り付けて保存する。

方法2：プラグインを使う（テーマに機能がない場合）

テーマ側に設定項目がない場合は、安全にコードを挿入できるプラグインを使用します。テーマを切り替えても設定が維持されるメリットがあります。

1. [プラグイン] ＞ [新規追加] で 「WPCode」 または 「Insert Headers and Footers」 を検索してインストール・有効化する。
2. 管理画面のメニューに「コードスニペット」が表示される。
3. 「ヘッダー」と書かれた入力欄に、AdSenseコードを貼り付けて保存する。

Google公式の 「Site Kit by Google」 プラインを使用すると、コードを手動でコピペする必要がありません。さらに、WordPressの管理画面内でAdSenseの収益やアクセス数（Analytics）を同時に確認できるようになります。

1. [プラグイン] ＞ [新規追加] で 「Site Kit by Google」 をインストール・有効化する。
2. 画面の指示に従って、ご自身のGoogleアカウント（AdSenseを所有しているアカウント）と連携する。
3. プラグインの設定内で「AdSense」を有効（オン）にすると、自動で最適なコードがWordPressに埋め込まれます。

---

## ⚠️ 設定後の重要な注意点

1. 広告が表示されるまで時間がかかります
設定完了後、実際に広告が表示され始めるまでに数時間〜数日かかることがあります。設定直後は「空白」になることが多いですが、エラーではないため少し時間を置いて確認してください。
2. 広告ブロックをオフにして確認する
先ほど確認したとおり、ご自身のブラウザのAdBlockが有効なままだと、正しく設定できていても広告が表示されません。確認時は「シークレットウィンドウ」を使用してください。
3. 広告が多すぎると感じた場合
自動広告の量が多すぎてブログのデザインが崩れる場合は、WordPress側ではなくAdSenseの管理画面（自動広告の設定）から、広告の掲載密度（量）を減らしたり、表示させたくない場所を除外したり調整できます。

---

作業を進めるにあたり、もし手順が分かりにくい場合は以下を教えていただけますか？

* 現在ブログで使用しているWordPressテーマの名前（例: Cocoon, SWELLなど）
* Google Analyticsなど、他のGoogleツールも一緒に管理したいか（Site Kitを導入したいか）

「旧暦2033年問題」とは、現在の旧暦（天保暦）のルールに従ってカレンダーを作ろうとすると、2033年の秋から2034年の春にかけて「旧暦の月名」が決められなくなってしまうという、カレンダー上の大問題のことです。1844年に天保暦が導入されて以来、初めて起こる事態です。

先ほど解説した「定気法」と「中気」の仕組みを踏まえると、なぜこんなことが起きるのかが分かりやすくなります。順を追って易しく解説します。

1. なぜ問題が起きるのか（原因）

前回の解説の通り、旧暦のルールでは「どの中気が入るか」で何月かを決め、中気が1つも入らない月を「閏月」とします。しかし、定気法の導入によって中気と中気の間隔が伸び縮みするようになった結果、「ひと月に中気が2つ入る月」や「中気が1つも入らない月」が不規則に発生するようになりました。

これによる混乱を防ぐため、天保暦では以下の強力な「固定ルール」を追加しました。

• 秋分（中気）を含む月は必ず「8月」とする
• 冬至（中気）を含む月は必ず「11月」とする
• （※春分は2月、夏至は5月とする）

ところが、2033年の秋から冬にかけて、中気が2つ入る月が2回、中気が1つも入らない月が3回も連続して発生するという極めて珍しい星回りになります。

すると、固定ルールによって「秋分を含む月＝8月」と「冬至を含む月＝11月」は確定するのですが、その間に「9月」と「10月」の2ヶ月分を入れなければならないのに、通常の月（中気を1つだけ含む月）が1回しかやってこないという事態が発生します。
結果として、9月と10月を当てはめることができず、旧暦のルールが完全に破綻してしまうのです。

2. どうやって解決するのか？

天保暦のルールだけでは解決できないため、どこかで妥協して独自の解釈（ルール変更）をするしかありません。専門家の間では主に以下の解決案が考えられました。

• 案1（冬至優先）：冬至を優先して当てはめる方法（これにより「閏11月」が発生する）
• 案2（秋分優先）：秋分を優先して当てはめる方法（これにより「閏7月」が発生する）
• 案3：その他の並べ方

3. 現状はどうなっているか？

現在、旧暦は公的な暦としては廃止されているため、国立天文台などの公的機関が「今年は案1でいきます」と決定することはありません。

しかし、カレンダーを作る業界では、旧暦や六曜（大安・仏滅など）が決められないとカレンダーを印刷できず大混乱になります。そこで、国立天文台のメンバーやカレンダー業界の団体が参加する「一般社団法人 日本カレンダー暦文化振興協会」が検討を行い、「案1（閏11月を置く）」を推奨するという見解を発表しました。
この見解は業界内で強い影響力を持つため、市販のカレンダーはおそらく「案1」に沿って作られることで問題が回避される見通しです。

（おまけ）中国では起こらない問題

旧暦（太陰太陽暦）を使用し、春節（旧正月）などを祝う中国ですが、この2033年問題は発生しません。中国の暦（時憲暦）は、「冬至を含む月から、次の冬至を含む月までに13ヶ月ある場合、最初の中気がない月を閏月にする」という非常にシンプルなルールを採用しているため、天保暦のように矛盾が生じないようになっています。（シンプルな平気法を採用しているからと言って、日本の定気法は複雑だから暦計算が優れていると考えるのは誤りです。時憲暦（清朝）以前の暦では定気法が採用されていたからです。天保暦のような問題が発生することを予見して、単純な平気法を採用したと見ることができます。）

具体的な数字を使った再説明

言葉だけでの説明では分かりにいので、表を使用し2033年の旧暦カレンダーがどのようになるかを改めて「旧暦2033年問題」を考えてみたいと思います。
以下は、資料に記載されている2033年秋から2034年春にかけての、新月（朔）と中気の配置、および想定される解決案の表です。

朔（新月の始まり）	含まれる中気	旧暦月（案1：推奨案）	旧暦月（案2）	旧暦月（案3）
2033/07/26	処暑 ( 8/23)	7月	7月	7月
2033/08/25	（中気なし）	8月	閏7月	8月
2033/09/23	秋分 ( 9/23)	9月	8月	9月
2033/10/23	霜降 (10/23)	10月	9月	10月
2033/11/22	小雪 (11/22), 冬至 (12/21)	11月	10月	11月
2033/12/22	（中気なし）	閏11月	11月	12月
2034/01/20	大寒 ( 1/20), 雨水 ( 2/18)	12月	12月	1月
2034/02/19	（中気なし）	1月	1月	閏1月
2034/03/20	春分 ( 3/20)	2月	2月	2月

なぜルールが破綻するのか？

旧暦（天保暦）の月名を決める基本ルールには、以下の強力な固定ルールが存在します。
「秋分」を含む月は必ず8月にする
「冬至」を含む月は必ず11月にする （※春分は2月、夏至は5月）
表の「含まれる中気」の列に注目してください。2033年の秋から冬にかけて、通常ではありえない星回りが発生します。
9月23日の新月から始まる月には「秋分」が含まれます。ルールに従えば、ここは「8月」にしなければなりません。
11月22日の新月から始まる月には「冬至」が含まれます。ルールに従えば、ここは「11月」にしなければなりません。
しかし、「8月（9/23〜）」と「11月（11/22〜）」の間には、10月23日からの1ヶ月分しかありません。間には「9月」と「10月」の2ヶ月分を入れなければならないのに、月が1つ足りないという決定的な矛盾が生じてしまうのです。
さらに、この時期には「中気が全くない月」が3回、「中気が2つもある月」が2回も密集して発生しているため、通常のように「中気のない月を閏月にする」という法則を当てはめることもできません。
どのように解決するのか？
「秋分＝8月」と「冬至＝11月」という両方の条件を同時に満たすことは不可能なため、どちらかのルールを妥協するしかありません。
案1（冬至優先）：「冬至を含む月＝11月」というルールを優先し、そこから遡って10月、9月、8月と当てはめる方法です。この場合、秋分のルールは妥協することになり、12/22〜が「閏11月」になります。
案2（秋分優先）：「秋分を含む月＝8月」というルールを優先して月名を当てはめる方法です。
この場合は8/25〜が「閏7月」になります
。
現在、カレンダー業界や国立天文台のメンバーなどで構成される「日本カレンダー暦文化振興協会」では、中国などの古い暦法でも冬至を定めることが暦の出発点であったことなどを踏まえ、「案1（冬至優先）」を推奨するという見解を出しています。

二十四節気の定め方には、大きく分けて「平気法（へいきほう）」と「定気法（ていきほう）」の2つの方式があります。この違いは、旧暦（太陰太陽暦）の閏月の置き方や暦の構造に大きな影響を与えました。

1. 平気法（恒気法／常気法）

平気法は、1年（約365.24日）という「時間」を単純に24等分して二十四節気を定める方法です。日本では江戸時代の天保暦より前の暦法で用いられていました。

1. 特徴: 各節気の間隔は常に一定で、中気と中気の間隔は1年÷12 ≒ 約30.4日となります。
2. 旧暦との関係: 月の満ち欠けの周期（1朔望月）はおよそ29.3〜29.8日の間で変化しますが、平気法の中気の間隔（約30.4日）の方が必ず長くなります。そのため、基本的には各月に中気が1個ずつ入り、「中気が1つも入らない月を閏月にする」というシンプルなルールで、暦と季節のズレを破綻なく調整することができました。

2. 定気法（実気法）

定気法は、天文学的な太陽の通り道（黄道）を基準とし、太陽の視黄経が15度の倍数になる瞬間ごとに二十四節気を定める方法です。日本では江戸時代末期の天保暦（1844年〜）から導入され、現在カレンダーなどで目にする二十四節気もこの定気法に基づいています。

1. 特徴: 太陽の視黄経を15度ずつ進むのにかかる時間は、季節によって変化します。これは、地球が太陽の周りをきれいな円ではなく楕円軌道で回っており、太陽に近づく冬（近日点付近）は公転速度が速く、遠ざかる夏（遠日点付近）は遅くなるためです。
2. 中気間隔の変動: この公転速度の遅速により、中気と中気の間隔も均等ではなくなり、冬は約29.5日と短く、夏は約31.5日と長くなります。

定気法の導入による旧暦の複雑化

季節の実際の変化に忠実な定気法ですが、太陰太陽暦のシステムに組み込むと厄介な問題を引き起こしました。

冬場は中気と中気の間隔（約29.5日）が、月の満ち欠けの周期（1朔望月）よりも短くなることが発生します。すると、「ひと月の間に中気が2回も訪れる月」や、逆に「本来は閏月を置くタイミングではないのに、中気が1つも入らない月」が出現してしまう可能性が出てきたのです。

これにより、「中気を含まない月を閏月にする」という従来のシンプルな原則だけでは、旧暦の月名が決められなくなる事態が生じました。
そこで天保暦では、二至二分（春分・夏至・秋分・冬至）を特定の月に固定する、以下のような強制的なルールを追加しました。

1. 冬至を含む月は必ず「11月」とする
2. 春分を含む月は必ず「2月」とする
3. 夏至を含む月は必ず「5月」とする
4. 秋分を含む月は必ず「8月」とする
天保暦を作成した人々は、より天文学的に正確な「定気法」を導入した結果、旧暦のルールを非常に複雑なものにしてしまいました。実は、この定気法と複雑なルールによって引き起こされる矛盾が、将来の旧暦の月名が決められなくなる「旧暦2033年問題」の根本的な原因となっています。

1. 二十四節気と太陽黄経との関連

二十四節気は、地球から見た太陽の通り道である「黄道」を基準に定められます。天文学的には、春分点（太陽が真東から昇り真西に沈む点）を「太陽黄経0度」とし、黄道を15度ずつ24等分して各区切りに季節を表す名称を付けたものです
。 これにより、春夏秋冬の4つの季節がそれぞれ6つに細分化されます。現在用いられている黄経15度ごとに区切る方式は「定気法」と呼ばれ、日本では江戸時代末期の天保暦から採用されました。太陽の実際の運行に基づいているため、季節感とよく一致するのが特徴です
。

2. 「中気」と「節気」の分類

二十四等分された節気は、さらに「中気（ちゅうき）」と「節気（せっき、正節とも）」の2種類に交互に分類されます。
中気: 太陽黄経が30度の倍数（0度, 30度, 60度…）になる日です。春分（0度）、穀雨（30度）、夏至（90度）、秋分（180度）、冬至（270度）などがこれにあたります。
節気: 中気と中気の中間である、太陽黄経が15度, 45度, 75度…になる日です。清明（15度）、立夏（45度）、立秋（135度）、立冬（225度）、立春（315度）などがこれにあたります。

3. 太陰太陽暦（旧暦）の月と「中気」との関連

太陰太陽暦（旧暦）は、月の満ち欠けの周期（新月から次の新月まで＝約29.5日）を1ヶ月の基準とします。
しかしこれを12ヶ月繰り返すと1年は約354日となり、太陽の動きで決まる実際の季節（1年約365日）に対して毎年約11日ずつ短くなってしまいます。 このズレを補正し、暦と季節を同期させるために用いられるのが二十四節気の「中気」です。
月名の決定: 旧暦では「どの中気が含まれるか」によってその月の名前（何月か）が決まります。例えば、「雨水（うすい）」が含まれる月を1月、「春分」が含まれる月を2月、「冬至」が含まれる月を11月とするなど、旧暦の月名の命名権は中気が握っています。
閏月の決定（無中置閏法）: 月の満ち欠けの周期（約29.5日）に対し、中気から次の中気までの間隔（約30.4日）の方が長いため、ごく稀に「中気を1つも含まない月」が発生します。旧暦では原則として、この中気を含まない月を「閏月（うるうづき）」として扱い、前月の名前を引き継いで「閏○月」と呼びます。
このように約3年に1度の割合で1年を13ヶ月にすることで、季節とのズレを調整していました。

4. 「節切り」における「節気」の役割

旧暦の月が「中気」で決まる一方で、中気と交互にやってくる「節気」は、九星気学や四柱推命などの占術・暦注において、年や月を区切る**「節切り（せつぎり）」**の基準として用いられます。
日常のカレンダーでは1日（ついたち）から月末までを1ヶ月としますが、節切りでは、太陽黄経が特定の角度（節気）に達した入節時刻をもって新しい年や月が始まるとみなします。
年の始まり: 1月1日や旧暦の元日ではなく、太陽黄経315度に達する「立春」の瞬間をもって年が切り替わります。
月の始まり: 毎月1日ではなく、各月の「節気」の瞬間で月が切り替わります。例えば、2月の始まりは「啓蟄（けいちつ・黄経345度）」、3月の始まりは「清明（せいめい・黄経15度）」、4月の始まりは「立夏（りっか・黄経45度）」となります。
このように、二十四節気は単なる季節の目安にとどまらず、旧暦における月名と閏月を決定するための「中気」システムと、気学などの占術において年・月を区分するための「節気（節切り）」システムという、暦を支える2つの重要な数理的役割を同時に果たしています。

jsonデータを生成する時には、確認し易くするため上記の方法で整形しているのだが、今回は何故かJSON_PRETTY_PRINTが有効にならず、一行の長～いテキストとして出力されてしまうのです。
オンライン json validator でチェックしても、フォーマットとしては全く問題がないにも拘わらず整形してくれないように見えます。
なぜか？
ググってみると回答がありました。
以下の通りにせよと。

‘Content-type: Application/JSON’ がないと、ブラウザにより’Content-type: Application/HTML’ と解釈されてしまい、1行の長～いテキストとして表示されるの原因だそうです。

とあるデータを入手したのだが、それには名称としてカナ名しか設定されていないので、次のような漢字名をDB（SQLite3）に追加するだけの単純なDB更新プログラムを作成してみた。

しかし、処理は正常に終了するものの、DBは更新されないのである。
原因不明なまま、悩まされること約1日。
漸くわかった、その原因。

bindParam の指定順番

 

の部分を

とすることで、更新が正常に行われるようになった。
何とも解せないのは、プレースホルダに “?” を使った次のような場合、

その指定順序は出現順に nameKanji、rkey としなければならないのは当然としても、名前（:name）を用いた場合は順序には関係なく指定できると考えていたのだが、どうもそうではないらということだ。

PDO のバグのような気はするのだが。。。私の PHP のバージョンが 7.2 と古いのでその所為かもしれないし、V8.0 以降はそんなバグっぽい現象はとっくに解消しているのかもしれないので、これ以上とやかく言うのはやめ現行の仕様に則り使って行くしかないでしょうな（くっ）。

それにしても無駄な時間を費やしたものだ。とほほ・・・

やまがた百名山

最近、youtube を見る機会が増えてきたが、中でも故郷山形の酷道・険道と称した動画が面白い。
車に積んだカメラで撮影しただけの動画ではあるが、故郷とは言え全く見たくことのない道路沿いの風景を見るのは楽しいものである。
特に、道路沿いの山々に興味を覚える。綺麗なオムスビ型の山や、奇妙な形の山、岩が露出した山などなど。
これを見ると、つい Google Map で位置を特定し、地理院地図でその山の名前を調べてしまうのである。

そのようなことを暫く行っていると、「やまがた百名山」というものがあることが分かってきた。どんな山が百名山に指定されているのかそのリストが欲しかったのだが、残念ながら「やまがた山」から一つ一つ調べるしかないらしい。
どうしても一覧表が欲しかったので、自分で作ったのが「やまがた百名山一覧」で、その位置を Google Map に示したのが「やまがた百名山の位置」である。
この百名山は、県内の山全体から登山家とか登山愛好者が厳選したものではなく、山形県を村山、最上、置賜、庄内の4地域に分け、その中から地元住民に親しまれている山を100座選んだものらしい。そのためか、鳥海、飯豊のような2000m を超える山もあれば、柏木山（飛島、58m）のような果たしてこれが山かと疑いたくなるようなものまで含まれている。しかし、国内には標高3mの山（日和山、宮城県仙台市）があって、人々がそれを「山」と呼べば高さに関係なく山になるらしいので、56mもありその地域で山と呼んでいればもう立派な山なのだろう。
生まれ育った寒河江市からは、1座のみ葉山（村山葉山、1462m）がエントリされている。身近に慣れ親しんできた長岡山（160m）、高瀬山（123m）は選外。名山かどうかはさておき、一番の思い出になる山なので一覧には、「番外」として記載しておくことにした。

DataTables

「やまがた百名山一覧」を作成する過程において、前回のブログで述べた「日本の主な山岳」も山名（漢字）と山名（かな）にそれぞれ地理院地と Google Map にリンクを張った「日本の主な山岳一覧」を作成した。
データ件数が1000件を超えると、さすがにこのままでは扱い難い。
Excelのようなフィルタリング機能、例えば、山形県のみを表示できるような機能を実現できるライブラリがないか探ってみた次第である。
そこで探し当てたのがこの「DataTables」で、HTMLテーブルに様々な機能を設定するjQuery ライブラリである。
これを使用すると、先程の「日本の主な山岳一覧」がどのように変化するかこちらを見て戴きたい。ちょっとプロっぽい体裁になっていると思う。
テーブル右上に「検索」という入力ボックスが配置されているが、ここに、例えば「山形県」とすると山形県を含むデータだけに絞ることができるので、フィルタリングとして使うことのできるものである。さらに、1ページ当たりの表示件数変更や、列ごとに昇順（▲）・降順（▼）に並べ替えることなども可能である。
この DataTables の機能については、DataTablesのサイトに詳細な説明があるのでそちらを参考に願いたい。
以上