アカウント名:
パスワード:
誰も気が付かないと思うし。
ところで、水晶発信器メーカーのエプソンのリアルタイムクロックICは、もともと32768Hzのかなり正確な水晶発振子を内蔵していますけど、精度の水晶発振子といえども個体ごとの固定的な偏差はあるので、IC内には、32768Hzの原信号から1秒をつくる分周器に「ある一定のタイミングで、1秒の長さを1/32768秒単位で伸ばししたり縮めたりする機能」が内蔵されていて、各ICごとにバラつきを校正できるようになっていました。
たしか、コンピュータの時刻関数でも、同様な手法でうるう秒をなだらかに吸収しているものがありましよね?
時報方式?(電話の時報は1分前から1/60秒ずつ長くしてうるう秒の挿入に対応してたはず)60秒の存在がまずいのでなければ,1秒ずれるという結果は同じなので,取り立てて効果は期待できないんじゃ?って思ったり。
時報方式?では、1分40秒前から、1/100秒づつです。
って一秒の定義を変えたらダメだろ。ミリ秒単位で調整してたら回数ばかり増えてよけい面倒になる。いままでどおりマメに1秒以内におさえるか、数十年に一回1分ずつにするか、1時間単位で調整するか、「それとも調整自体をやめちゃおうか?」話なんだから。
わかってない国だなって言われちゃうぞ。
いっそ、 地球の公転周期を人為的に変えてはどうか?
2/29(うるう年)、うるう秒、サマータイムの処理いずれもなんですが、基準となる日時から時刻を求める計算式で吸収すべきで、時間の長さを変えてはいけません。
そういう時刻補正のパラメータは、定義に従って見える形で補正してあげないと、ログとか時刻を特定しなければならない情報が破たんしてしまいます。
ちなみにIBMおよびその互換メインフレームでは、何十年も前からH/W内部にローカルタイム、サマータイムやうるう秒補正用のテーブルを設定できるようになってますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
いっそ、毎月月末に、ミリ秒単位で修正したほうがいいかも。 (スコア:1)
誰も気が付かないと思うし。
ところで、水晶発信器メーカーのエプソンのリアルタイムクロックICは、もともと32768Hzのかなり正確な水晶発振子を内蔵していますけど、精度の水晶発振子といえども個体ごとの固定的な偏差はあるので、IC内には、32768Hzの原信号から1秒をつくる分周器に「ある一定のタイミングで、1秒の長さを1/32768秒単位で伸ばししたり縮めたりする機能」が内蔵されていて、各ICごとにバラつきを校正できるようになっていました。
たしか、コンピュータの時刻関数でも、同様な手法でうるう秒をなだらかに吸収しているものがありましよね?
Re:いっそ、毎月月末に、ミリ秒単位で修正したほうがいいかも。 (スコア:2)
Re:いっそ、毎月月末に、ミリ秒単位で修正したほうがいいかも。 (スコア:2)
時報方式?(電話の時報は1分前から1/60秒ずつ長くしてうるう秒の挿入に対応してたはず)
60秒の存在がまずいのでなければ,1秒ずれるという結果は同じなので,取り立てて効果は期待できないんじゃ?って思ったり。
Re: (スコア:0)
時報方式?では、1分40秒前から、1/100秒づつです。
Re: (スコア:0)
って一秒の定義を変えたらダメだろ。ミリ秒単位で調整してたら回数ばかり増えてよけい面倒になる。
いままでどおりマメに1秒以内におさえるか、数十年に一回1分ずつにするか、1時間単位で調整するか、
「それとも調整自体をやめちゃおうか?」話なんだから。
わかってない国だなって言われちゃうぞ。
それならば、 (スコア:1)
いっそ、 地球の公転周期を人為的に変えてはどうか?
時間をずらして調整してはいけません (スコア:0)
2/29(うるう年)、うるう秒、サマータイムの処理いずれもなんですが、
基準となる日時から時刻を求める計算式で吸収すべきで、時間の長さを
変えてはいけません。
そういう時刻補正のパラメータは、定義に従って見える形で補正してあげないと、
ログとか時刻を特定しなければならない情報が破たんしてしまいます。
ちなみにIBMおよびその互換メインフレームでは、何十年も前からH/W内部に
ローカルタイム、サマータイムやうるう秒補正用のテーブルを設定できるように
なってますね。