orange @[email protected]

＞＜

普通に使う日時の型は、その環境が扱いやすい型で扱えば処理も軽量でいい感じだろうけど、TAIを扱う場面って厳格さが要求される場面に限られるだろうし、そんな場面でも未定義を残すんかいC(C++)文化圏は・・・＞＜
という感想＞＜

Adaの標準ライブラリってTAIとUTCの相互変換のサポートあるのかな？＞＜

これだからC＆C++は・・・＞＜

tai_clock - cpprefjp C++日本語リファレンス https://cpprefjp.github.io/reference/chrono/tai_clock.html

"rep 時間間隔の内部表現となる符号付き算術型。具体的な型は未規定"
🤔

.NETのDateTime, DateTimeOffset, TimeSpanに頼りきるのダメだった事例っぽさ＞＜；
コア部分ほとんど一晩で作ったからあれだけど＞＜；

世の中の大半の物事、閏秒は跨ぐ瞬間以外考慮する必要がないけどオレンジが作ってたアプリは考慮しないとダメだった少ない事例だったかも＞＜；(してなかった＞＜；)

国際原子時と協定世界時 https://www.pahoo.org/e-soul/webtech/time/time05-01.shtm

オレンジが作ったロケット打ち上げとかのシーケンスとかを表示するやつ、普通に.NETのDateTimeとか使っててUTCで計算してるけど、長いミッションのミッション時間(例えばISSのMET)ってよく考えたらTAIで計算し直さないとと言うか閏秒を除外するように計算しないと正しくない？＞＜

民生用というか一般人が変えるお値段のGPSレシーバーでは、GPSがしゃべってる閏秒の情報は受け取れない(機器内でUTCに変換しちゃう)っぽい・・・？＞＜

signed版だけじゃなくunsigned版も作ったら、色々なbit詰めてあるバイナリなフォーマットの読み書きするやつを書く時に手抜きができる？＞＜；

当たり前だけど、任意のbit長のUNIX Timeを簡単に作れるようになった＞＜

C# で任意のbit数(bit長)の符号付整数型になる手抜きなやつ、一応ちゃんと（？）動くやつ作れた＞＜
デバッグちょっとしかして無いのでバグってるかもしれないけど＞＜；

たまご高騰問題、一般家庭向け（おうちでの調理用）だけで言えば、他の食材のお値段と比べると今までが安すぎた気がしなくも無い・・・＞＜（個人的感覚＞＜）（だからこそ物価の優等生って言われてたんだろうし＞＜）

インチキすぎて（完成させても）普通の計算用途には1ミリも役に立たないけど、bit詰め詰めなデータフォーマットの中に出てくる数値表現に変換するやつとしては便利そう＞＜

任意のbit数に対応するようにした＞＜；

オレンジ方式ってインチキすぎると思ったけど、オレンジ方式だったら(64bit未満の)任意のbit数に動的に対応するやつも作れる・・・？＞＜

＞＜；

先人を見つけて「やっぱそうか＞＜； 」になった＞＜；
BitStream/Int48.cs at master · rubendal/BitStream · GitHub - https://github.com/rubendal/BitStream/blob/master/Int48.cs
もっとシンプルに書けないのかな？＞＜；