127：名無し：2025/05/31(土) 15:50:57.887ID:AD/ooLfoJ

public static const TEN = 10;

136：名無し：2025/05/31(土) 15:56:04.121ID:V3bzUKhjX

日本企業はERPパッケージの個別カスタマイズとか入れまくるから
検証とかも馬鹿にならんと思うけどね

130：名無し：2025/05/31(土) 15:51:57.970ID:r5fDXQKxQ

増税はよくあることやから対応簡単やけど、減税なんてすることないから対応難しいん？

135：名無し：2025/05/31(土) 15:55:48.849ID:punViw96U

だって税率変更出来るようにしたらせっかくの買い替え需要がなくなるからな…

140：名無し：2025/05/31(土) 15:59:56.516ID:f9XqIWuDM

増税君は簡単に出来るのに減税君は何で出来ないんだい？
もう減税君はしっかりして！

144：名無し：2025/05/31(土) 16:03:31.949ID:RBIY0SOYP

こんな有様じゃ2038年問題乗り越えられなさそう
2038年問題 - Wikipedia

2038年問題（にせんさんじゅうはちねんもんだい）は、協定世界時（UTC）2038年1月19日3時14分7秒（日本標準時の場合、1月19日12時14分7秒）を過ぎると、コンピュータが誤動作する可能性があるとされる年問題。

（中略）

伝統的な実装ではtime_tをintまたはlongのtypedefによる型エイリアス（別名）とし、その型は符号付き32ビット整数型であった。このため最大値は (231 ? 1) = 2,147,483,647 となり、取り扱えるのは2,147,483,647秒（≒ 68年）までに限られていた。これを前提として作成されたプログラムは、協定世界時における1970年1月1日0時0分0秒（日本標準時では1970年1月1日9時0分0秒）から2,147,483,647秒を経過した、2038年1月19日3時14分7秒（日本標準時では2038年1月19日12時14分7秒、閏秒は考慮していない）を過ぎると、この値がオーバーフローし[注釈 2]、もし時刻を正しく扱えていることを前提としたコードがあれば、誤動作する。

全文はこちら
https://ja.wikipedia.org/wiki/2038%E5%B9%B4%E5%95%8F%E9%A1%8C

145：名無し：2025/05/31(土) 16:06:35.929ID:V3bzUKhjX

そりゃ90何%のシステムは設定変えるだけだから数日で何とかなる
残りの数%を切り捨てるかどうか切り捨てないなら1年コース