[
新規
] - [
ツリー
] - [
スレッド
] [
未解決
] [
緊急
] - [
優先
] - [
検索
] - [
なでしこTOP
]
「なでしこv1」開発掲示板
なでしこv1のバグや要望を書き込む掲示板
→
書き込み(
#3008
)を編集する:
名前
タイトル
本文
Delphiは分かりませんが、主にコメントを眺めて、なんでこのようなナゾ日付が発生するのかと言うことは分かりました。 例えば、「2028/09/20」。 これは「2028/08/02」が正解なのですが、修正前だと7/32に、現在は8/2を飛ばして8/3となってしまうやつです。 #----------------------------------------------- 開始日=「2028/09/18」 6回 開始日を旧暦変換して、「{開始日},{それ}」を表示。 開始日は開始日に「+0/0/1」を日付加算。 #----------------------------------------------- この年の秋分は9/22です。 なので、直前の二分二至は夏至とゆうことになります。 夏至は6/21で、これは旧暦05/29に当たります。 これの直前の朔は、旧5/1にあたる2028/05/24となり、これをスタートに4回計算を繰り返して、5行の朔日行列を作ってるわけですよね? 計算で作ってませんが、こうなるものと思われます。 #----------------------------------------------- tm0=「2028/09/20」の修正ユリウス日取得。//62034 m=「5,0,61915 5,1,61945 6,0,61974 7,0,62003 8,0,62033」 #----------------------------------------------- 目的の旧8月が最後の行になっているので、朔日行列から旧暦を求めるところでは、日付の計算はm[4][2]を見て行わなければなりませんが、どうも「Dec(j)」が、でくりめんと? j=j-1とゆうことだとすると、m[3][2]前月の7月を見て計算してることになっちゃいますよね。これだとたしかに7/32になりまする。 秋分を過ぎた9/23から正しく戻るのも、直前の二分二至が秋分に変わり朔日行列が変化するからですよね。 state=0になってDec(j)するべきなパターンがよく分かりませんが、とりあえず、tm0がm[4][2]より大きかった場合は、stateを2とか3とかにしてDec(j)しないようにしたら・・・なおったりしませんかねえ・・・
優先度
低
中
高
緊急
状態
未処理
詳細求む!
調査中
議論中
修正中
確認待ち
再修正依頼
解決
---
重複
---
アイデア
感想
告知
感謝
確認キー
👆お手数ですが、いたずら防止のために、「真夏」の読み方を記入してください。
編集キー
編集時に使うキーを入力(省略可能)
添付ファイル
🎁
ファイルを選択...
画像ファイル(最大300KB)を添付可能