●日付の表現の仕方
前職では日付は８桁の文字として処理していました
現職では日付の年と月と日をそれぞれ４桁、２桁、２桁の数値として処理しています
前職の方が扱いやすかった………
でも、数値のほうがコンパイラにとっては良いのかも
●そんなことはない
RPG4では、日付型の変数も使えるようにはなっている
でも、今から新規開発するシステムでもない限り
文字列型や数値型の日付フィールドを日付型に変更するなんてことはしない
変更のための努力の結果得られるのは
開発者の達成感だけ（笑）
利用者は………何も恩恵が得られない（笑）
やるだけ無駄
●変なとこ
こないだ、システム改修のためにプログラムソースを見た
その会社のシステム、ソースを見た限りなんだか変だ
AS/400のソースは一行ごとに更新日付が付されている
なので、それを見るとどこのロジックをいつ変更したかがだいたい見当がつく
●2029年？？？
でもその会社のシステムのプログラムソースを見たら
290408とか設定されているのがあった
おかしいな？このフィールドはYYMMDDのはずなのに
まさか欧米式にMMDDYYとかDDMMYYで入力されているのか？
もっと見ると、右2桁に31とか入力されているのを見つけてしまった
さっぱり理由がわからず、そこを担当するもう一人に聴いてみた
すると、驚くべき答えが………
人気ブログランキング
" allowfullscreen>タグ：日付表現
【このカテゴリーの最新記事】
-
no image
-
no image
-
no image
-
no image
-
no image
ご経験がおありなんですね(笑)
そう、そのまさかです。
しかも、システムタイマを和暦で設定していたので、2000年1月1日には、システムタイマは120101となっていたわけです。
この調子で和暦を使用し続けていたので、その時からシステムの全ての日付が和暦になっています。
ジョブログも、オブジェクトの使用日も・・・
ブログではソースをみたら変な日付としていますが、実際にはそのシステムのオブジェクトの利用履歴を取得し、最新使用日付が半年以上前のものならチェック対象外にしようとしたんですが、なんと最新の使用日付が未来になっているものがあり、おかしいと思い使用状況を把握しようとソースを見たら・・・って筋です（笑）
そして、平成から令和に切り替わった時、つまり2019年5月1日に、さすがに010501にできなかったのか西暦に替えたとか
ただ、それまで刻印された日付情報はそのままにして
なので、310430の次が190501となってしまったわけです。
その後5年以上使用したら、和暦と西暦が入り混じった状態になり、なんとか区別してと思いましたが、１時間で断念しました。
よくもまぁこんな管理の仕方をする企業があったもんです。
自分のところで簡単なプログラムでも組めたら、西暦⇔和暦変換なんて簡単なんですけどね😉
令和になってから５年以上経過し、平成という元号も頭の片隅から消えかかっていますよね。
でも、平安時代はタイムスリップし過ぎですよね(笑)
お疲れ様です。
>>すると、驚くべき答えが………
まさかの和暦ですかね。
昭和→平成の際に西暦化していると思いますが。。。
290408・・・なら平成時代も和暦だった？
現職の会社では
業務システム内の日付は 平成まで 和暦だったようです。
ソースに 620630 とあるので システム的には平成に入り西暦化の感じ。
和暦だと Y2Kは影響なしだったんですかね？
自分で書いておきながら
「平成時代」→「平安時代」と錯覚してしまいました(笑)