アカウント名:
パスワード:
ROMの容量?日時を記録するS-RAMのbit数?
そういうたぐいの制限なら2020年1月1日なんてところに限界は来ないはずなので人為的に区切ったと考えられる。
「2019年まで使えれば十分やろ」で適当なコードを書いてたプログラマが原因でしょう。発売年から2019年までのswitch〜case文が書かれている様子が想像できます・・・・・
仕様として、携帯電話として使える期限まで使えればいいという考え方もあるでしょうね。
下記は今後の話ですが、今回カレンダーが使えなかったケータイは、いつまでの規格に対応してたんでしょうか。もちろん、ユーザーは期限後もカレンダーが使えるべきと考えるでしょうけど。
au、2022年3月末で3Gサービス「CDMA 1X WIN」を終了 [impress.co.jp]
「2019年まで使えれば十分やろ」で適当な仕様を書いてた設計者が原因でしょう。
ということ?保証期間が書かれたものはあっても、○○○○年以降使えなくなるなんて書かれた取説なんて存在するのかな。
使えなくなるとは書いてないけど、私の使っているN-01Gは取扱説明書の55頁に「設定できる日付・時刻は、2004年1月1日00時00分から2037年12月31日23時59分までです。」と書いてあるから、カレンダーもそこまでしか存在しないんでしょうね。N-01G 取扱説明書(詳細版) [nttdocomo.co.jp]祝日も347頁に書いてある内容からすると固定データのようですね。
tiime_t 型が32bitっていう技術的制限を越えられなかったから切りの良い2037年という所で区切った説を推したい。
会計上の耐用年数は10年だから、それに合わせては作ってあるんじゃない?
# というか、カレンダーだけが問題ではない# (ヒンジや液晶、バッテリー等の部品故障もありうる)のだから# 「何年までは使用できる」(保証期間)は書けても、# 「取説に何年以降は使えなくなる(それまでは使えると読める)」# は書けないんじゃ・・・。20年以降使えなくなると書いていて、# 18年に故障したら文句言うでしょ?
取説に設定できる日付の範囲は2000年1月1日から2019年12月31日までと書かれていましたとさ。https://tech.nikkeibp.co.jp/atcl/nxt/news/18/06797/?i_cid=nbpnxt_ranking [nikkeibp.co.jp]途中で壊れても文句言えないね。ちゃんちゃん
そういう指示が有った時は、それ以降が出せると逆に文句付けられたりするからなあ。
仕様はキャリア側のね
端末メーカーはキャリアの言いなりなので、「メモ帳の保存件数は最大10件」と言われればそのとおりにするだけ
機能によっては、各メーカーの担当者集めて仕様を協議したりするけど、とにかくキャリアの意向が最優先される
取説にカレンダー範囲が明示されているのは一般的だったと思うけど。
カレンダーの設計要求仕様に「年月範囲:1980年1月1日から2019年12月31日まで問題無く動作すること」とか書いてあったに1ペリカ
取説に書いてあった。http://media.kddi.com/app/publish/torisetsu/pdf/w41s_torisetu.pdf [kddi.com]
>日付・時刻を設定する>●2000年1月1日から2019年12月31日の範囲で入力できます。
曜日を1970/01/01とか何かの日付を基点に算出してたりね・・・そしてこんな事する奴に限って閏年を理解せずに経過日数を算出しているという・・・
何年後だろうと曜日くらいツェラーの公式で算出できるだろ
そう、でも#3739710みたいなのが未だにいるわけで。最近は言語(ライブラリ)が日付処理対応してるのでまず見なくなったのですが。
>曜日を1970/01/01とか何かの日付を基点に算出してたりね・・・UNIX時間 - Wikipedia [wikipedia.org]
> 曜日を1970/01/01とか何かの日付を基点に算出してたりね
基点なしで曜日なんて計算できないのでは?
甘いな。多分全部テーブルだ。
なんのためにswitch文が必要?
俺は三項演算子派だ!(さらに混ぜ返す)
そうそう。switch文なんて不要ですよね。 (Perl脳)
税金の制度とかを見る限り、数式で何とかしようとせずに場合分けで列挙する人種は存在する。
数式で何とかしたのをスマートな解決と感じずになんじゃこりゃと思う人種、かもしれない仕様に合致しているかを、テストではなくコードと仕様の合致でチェックする人種、だったりするかも
言いたいことは理解できますが、どっちがいいかは場合によりけりとしか。
例えば、最大値、最小値、絶対値などを場合分けで列挙するのは、頭悪いと思いますが、税金やら年金やらは、数式で書かれるよりは、場合分けのほうがパッと見て理解しやすいと思います。
OSに相当するであろうKCP側がウンコだったのか、カレンダーアプリがダメなだけなのか切り分けしたいけどこの頃のガラケーって自作アプリを直接実行する事って今の時代出来るんだろうか
つまり、保証期間過ぎても端末が壊れない限り永遠に動く保証のないコードは悪いコードということ?
普段サポートされない古いOSを叩くくせに
叩きながらオフラインで使うんじゃないか。トンテンカンテン(擬音)。
ドヤ顔で書いてフルボッコで反論されて「仕事だけでなくスラドでもかよ」と正月早々発狂している様子が想像できます・・・・・
基本的にこの手はLinuxのシステム時計の仕様に沿う筈ですけどそれなら2038年まで使える筈ですからかなり変な組み方してるんでしょうね
ガラケーだからLinuxは少数派で、TRONとかBREWとかじゃないですかね。
> かなり変な組み方してるんでしょうね Linux屋からみると超絶変だと思います。
NとかPは中Linuxのやつもありましたが。外面は自前なのでカーネル作るのめんどいから持ってきたような体裁ですが。
昔の組み込みは特別の理由がなければRTCがネイティブで表現できる範囲でやってたからUNIX時間はあまり使わなかったよ。特別な理由ってのは本気で正確な時刻を扱う必要があるシステムか、元々OSがUNIX時間をサポートしてる場合ね。
2038年だろうが上限判定はやるんだから、組み方は変わんねーよ。
仮にUNIX時間使っていたとしても、一般人には2038年問題なんて無縁なんだから携帯の耐用年数との兼ね合いでキリの良い2020年にしてるるだけでだろ。
想像だけど、祝日の計算をさぼるために、2019年までの祝日をテーブルに登録(switchで実装しているかもしれないが)。
2020年以降は祝日が反映されないため、表示しないようにしているとかないでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
何が制限になったのか (スコア:0)
ROMの容量?日時を記録するS-RAMのbit数?
Re:何が制限になったのか (スコア:1)
そういうたぐいの制限なら2020年1月1日なんてところに限界は来ないはずなので人為的に区切ったと考えられる。
Re: (スコア:0)
「2019年まで使えれば十分やろ」で適当なコードを書いてたプログラマが原因でしょう。
発売年から2019年までのswitch〜case文が書かれている様子が想像できます・・・・・
Re:何が制限になったのか (スコア:3)
その程度の年またぎ時の仕様は日本の大手メーカー製品なら普通に策定しますし
テストもやってますし、取説にもその旨は書かれていることでしょう。
プログラマはちゃんと仕事をしています。
Re:何が制限になったのか (スコア:2)
仕様として、携帯電話として使える期限まで使えればいいという考え方もあるでしょうね。
下記は今後の話ですが、今回カレンダーが使えなかったケータイは、いつまでの
規格に対応してたんでしょうか。
もちろん、ユーザーは期限後もカレンダーが使えるべきと考えるでしょうけど。
au、2022年3月末で3Gサービス「CDMA 1X WIN」を終了 [impress.co.jp]
-- う~ん、バッドノウハウ?
Re: (スコア:0)
「2019年まで使えれば十分やろ」で適当な仕様を書いてた設計者が原因でしょう。
ということ?
保証期間が書かれたものはあっても、○○○○年以降使えなくなるなんて書かれた取説なんて存在するのかな。
Re:何が制限になったのか (スコア:3, 参考になる)
使えなくなるとは書いてないけど、私の使っているN-01Gは取扱説明書の55頁に「設定できる日付・時刻は、2004年1月1日00時00分から2037年12月31日23時59分までです。」と書いてあるから、カレンダーもそこまでしか存在しないんでしょうね。
N-01G 取扱説明書(詳細版) [nttdocomo.co.jp]
祝日も347頁に書いてある内容からすると固定データのようですね。
Re: (スコア:0)
tiime_t 型が32bitっていう技術的制限を越えられなかったから切りの良い2037年という所で区切った説を推したい。
Re:何が制限になったのか (スコア:1)
会計上の耐用年数は10年だから、
それに合わせては作ってあるんじゃない?
# というか、カレンダーだけが問題ではない
# (ヒンジや液晶、バッテリー等の部品故障もありうる)のだから
# 「何年までは使用できる」(保証期間)は書けても、
# 「取説に何年以降は使えなくなる(それまでは使えると読める)」
# は書けないんじゃ・・・。20年以降使えなくなると書いていて、
# 18年に故障したら文句言うでしょ?
Re: (スコア:0)
取説に設定できる日付の範囲は2000年1月1日から2019年12月31日までと書かれていましたとさ。
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/06797/?i_cid=nbpnxt_ranking [nikkeibp.co.jp]
途中で壊れても文句言えないね。ちゃんちゃん
Re: (スコア:0)
そういう指示が有った時は、それ以降が出せると逆に文句付けられたりするからなあ。
Re:何が制限になったのか (スコア:1)
仕様はキャリア側のね
端末メーカーはキャリアの言いなりなので、
「メモ帳の保存件数は最大10件」
と言われればそのとおりにするだけ
機能によっては、各メーカーの担当者集めて仕様を協議したりするけど、
とにかくキャリアの意向が最優先される
Re: (スコア:0)
取説にカレンダー範囲が明示されているのは一般的だったと思うけど。
Re: (スコア:0)
カレンダーの設計要求仕様に
「年月範囲:1980年1月1日から2019年12月31日まで問題無く動作すること」
とか書いてあったに1ペリカ
Re: (スコア:0)
取説に書いてあった。
http://media.kddi.com/app/publish/torisetsu/pdf/w41s_torisetu.pdf [kddi.com]
>日付・時刻を設定する
>●2000年1月1日から2019年12月31日の範囲で入力できます。
Re: (スコア:0)
曜日を1970/01/01とか何かの日付を基点に算出してたりね・・・
そしてこんな事する奴に限って閏年を理解せずに経過日数を算出しているという・・・
Re:何が制限になったのか (スコア:2)
何年後だろうと曜日くらいツェラーの公式で算出できるだろ
Re: (スコア:0)
そう、でも#3739710みたいなのが未だにいるわけで。
最近は言語(ライブラリ)が日付処理対応してるのでまず見なくなったのですが。
Re: (スコア:0)
>曜日を1970/01/01とか何かの日付を基点に算出してたりね・・・
UNIX時間 - Wikipedia [wikipedia.org]
Re: (スコア:0)
> 曜日を1970/01/01とか何かの日付を基点に算出してたりね
基点なしで曜日なんて計算できないのでは?
Re: (スコア:0)
甘いな。
多分全部テーブルだ。
Re: (スコア:0)
なんのためにswitch文が必要?
Re: (スコア:0)
俺は三項演算子派だ!(さらに混ぜ返す)
Re: (スコア:0)
そうそう。switch文なんて不要ですよね。 (Perl脳)
Re: (スコア:0)
税金の制度とかを見る限り、
数式で何とかしようとせずに場合分けで列挙する人種は存在する。
数式で何とかしたのをスマートな解決と感じずになんじゃこりゃと思う人種、かもしれない
仕様に合致しているかを、テストではなくコードと仕様の合致でチェックする人種、だったりするかも
Re: (スコア:0)
言いたいことは理解できますが、どっちがいいかは場合によりけりとしか。
例えば、最大値、最小値、絶対値などを場合分けで列挙するのは、頭悪い
と思いますが、
税金やら年金やらは、数式で書かれるよりは、場合分けのほうがパッと見て
理解しやすいと思います。
Re: (スコア:0)
OSに相当するであろうKCP側がウンコだったのか、カレンダーアプリがダメなだけなのか切り分けしたいけど
この頃のガラケーって自作アプリを直接実行する事って今の時代出来るんだろうか
Re: (スコア:0)
つまり、保証期間過ぎても端末が壊れない限り永遠に動く保証のないコードは
悪いコードということ?
Re: (スコア:0)
普段サポートされない古いOSを叩くくせに
Re: (スコア:0)
叩きながらオフラインで使うんじゃないか。トンテンカンテン(擬音)。
Re: (スコア:0)
ドヤ顔で書いてフルボッコで反論されて
「仕事だけでなくスラドでもかよ」と正月早々発狂している様子が想像できます・・・・・
Re: (スコア:0)
基本的にこの手はLinuxのシステム時計の仕様に沿う筈ですけど
それなら2038年まで使える筈ですから
かなり変な組み方してるんでしょうね
Re: (スコア:0)
ガラケーだからLinuxは少数派で、TRONとかBREWとかじゃないですかね。
> かなり変な組み方してるんでしょうね
Linux屋からみると超絶変だと思います。
Re: (スコア:0)
NとかPは中Linuxのやつもありましたが。
外面は自前なのでカーネル作るのめんどいから持ってきたような体裁ですが。
Re: (スコア:0)
昔の組み込みは特別の理由がなければRTCがネイティブで表現できる範囲でやってたからUNIX時間はあまり使わなかったよ。
特別な理由ってのは本気で正確な時刻を扱う必要があるシステムか、元々OSがUNIX時間をサポートしてる場合ね。
Re:何が制限になったのか (スコア:1)
年表現を5ビット(Y1, Y2, Y4, Y8, Y10)にケチってたら19年で終わるかなぁとふと思いました。
Re: (スコア:0)
2038年だろうが上限判定はやるんだから、組み方は変わんねーよ。
仮にUNIX時間使っていたとしても、一般人には2038年問題なんて無縁なんだから
携帯の耐用年数との兼ね合いでキリの良い2020年にしてるるだけでだろ。
Re: (スコア:0)
想像だけど、祝日の計算をさぼるために、
2019年までの祝日をテーブルに登録
(switchで実装しているかもしれないが)。
2020年以降は祝日が反映されないため、
表示しないようにしているとかないでしょうか?