[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jamsat-bb:5141] QT98 Y2K (2000.2.29)
QT98 V4.0JにY2K問題（閏日の不具合）が発生しました。
皆さんのトラッキング・ソフトは大丈夫でしょうか？
先日、配送されたORBS.063をQK.EXEで変換し、QT98 V4.0Jに読み込んで
計算したところ、「本来のパスの時刻」に１日プラスされたものが計算
結果として表示されていることに気付きました。
即ち、09MAR100 hhmmss であるべきところが、10MAR100 hhmmss という
結果として出力されているのです。どうやら、忘れた頃にY2K問題が発生
したものと考え、その原因と対策について検討してみました。
以下、簡単に、その検討結果を報告したいと思います。
１．状況
不具合の内容については、上述のとおり。
２．原因
閏日（２月２９日）の影響（認識されていない。）と考えられる。
【本来の対応】
ORBS 058 059 060 061 062 063 ←UPDATE.DATの日付
2/27 2/28 2/29 3/1 3/2 3/3 ← 暦の日付
【今回の対応】
ORBS 058 059 060 061 062 063 ←UPDATE.DATの日付
2/27 2/28 3/1 3/2 3/3 3/4 ← 暦の日付
例えば、ORBS.062には、本来3月2日が該当すべき（上段）ところ、閏日の影響
を受けて、実際の日付に+1日した＝3月3日（下段）として認識されてしまう。
この不具合の発生原因について考える。
��QK.EXEが閏日を認識しないままKEPFILE,STNMFILEを書き換えている。
��QK.EXE自体は閏日をカウントし正常に処理するが、KEPFILE,STNMFILEをQT98が
読み込む際に、閏日をカウントせずに軌道計算した結果を出力している。
��QT98自体が2000.2.29を認識していない。（Y2K対応できていない。）
これについては、結果出力に2000.2.29を出力（来年は無しを確認）しており、
正常に軌道計算されていることを確認した。
種々の状況を想定した結果、上記�＾燭い蓮↓△�原因であると判断した。
３．対策
不具合の対応策として、次の２つを確認した。
【その１】
��QK.EXEにより、送られてきたORBSデータでKEPFILE,STNMFILEを更新する。
�△修里泙�QT98で、更新されたファイルを読み込む。
��EDITで、通常のKEPFILEの修正（EPOCHの部分のみ再入力する作業）をする。
��EPOCHの再入力の際、表示された日付から -1日して入力する。
即ち、03MAR00 hhmmss ならば、02MAR00 hhmmss と入力することによって、
02MAR100 hhmmss として、本来の正しい関係が認識される。
【その２】
�〇�前に、送られてきたORBSデータの日付部分を書き換える。
即ち、062.XXXXXX の部分を -1日して、061.XXXXXX と書き換え、保存する。
�△修里泙�QT98で、更新されたファイルを読み込む。
��EDITで、通常のKEPFILEの修正（EPOCHの部分のみ再入力する作業）をする。
��EPOCHの再入力の際、表示された日付をそのまま再入力する。
即ち、02MAR00 hhmmss ならば、そのまま 02MAR00 hhmmss と再入力すること
によって、02MAR100 hhmmss として書き換わり、正しく認識される。
※なお、この対応は1999年の通日処理でも可能だと思われますが、確認はして
いません。その際に注意すべきことは、この場合も通常の365日加算を364日
の加算として、-1日のオフセットをとることが必要となることです。
ＪＨ４ＤＨＸ／３ 大谷 Mar.9 2000