アカウント名:
パスワード:
「北朝鮮の朝鮮中央通信は30日、最高人民会議常任委員会が同日、北朝鮮の標準時間を30分早める政令を採択し、 [huffingtonpost.jp]5月5日から適用すると報じた。」
発表から切り替え実行まで1週間しかないなんて、リアルタイムクロックが組み込まれたハードウェア、それをもとに動くソフトウェア、ネットワークでつながったそういった装置間での、時間の切り替えタイミングのずれなどで問題が起きないか、1週間でチェックさせられる向こうの国のエンジニア達に同情する。
まったく、独裁者の居る国ってのはこうだから…。
その機能が有って、かつ、それで済むシステムなら「タイムゾーンをソウルにする」ところが続出する気が
どこかの国は元号対応まで2ヶ月も猶予があるからな,なんてエンジニアに優しい国なんだ.
元号が変わるというのはずっと前から分かっていて、具体的な名前が決まるのがギリギリというだけなら、ソフトウェア的には、いかようにも準備のしようがあるのではないか?
そっちのほうは、カレンダーなどむしろアナログの業種のほうが大変だろうな。印刷所のキャパってものがあるだろうし。
そう、むしろ今回の改元の方が異例なんだよね本来、改元はいつ起こるか分からない前提で対応するべきものギリギリで提示した方がいい
2000年が来るというのは(人類滅亡でもしない限り)確実にわかっていて、しかもギリギリまで仕様が決まらないような要素もなかったわけだが
だからちゃんと準備できたじゃないか。
こういうバカが「準備期間なんかいらない」とか言い出したのか
まさか準備したいから1年ぐらい時間止まって欲しいとか思ってんの?!
ウケるよねw
元号はいつ変わるかわからないのだから「未来の日付に対してDateTime.ParseExact()してはならない」ってことだぞ。しかも未来ってのは開発時点より未来だ。ユーザーが入力するような、内容を制御できないものについては言うまでもなく使えない。
バージョン1803ではたまたまそれが表面化しただけなのに、結局MSがエラーにしないよう修正して尻拭いする羽目になったんだから、世間の程度はお察しだ。
いや、もともと8.5時間ずれに対応できなかった現状承認じゃね。屍の山が築かれないようにという独裁者の優しさだよ、これはw
国防レーダーが電力不足で動いていない国で、時間がずれたからって、なんの問題になるだろう。
日時計の据え付け角度をπ/24rad程修正する必要がある。無論機械式時計でも長針をπrad進める補正が必要。
その切替の時間帯を計画停電にすれば良いんじゃねぇ。
要は独裁者の国家なら発想の転換でいくらでも解決できる
Windowsの場合、8.5時間時差(平壌時間)導入時に専用のタイムゾーン「UTC+08:30 平壌」を追加する対応を取っていました。https://support.microsoft.com/en-us/help/3093503/ [microsoft.com]
今回の変更で時差が元に戻った場合、このタイムゾーンはどうなるんでしょうか。タイムゾーンの追加や変更はちょくちょくあっても、削除はあまり見たことがないので、ちょっと気になります。
・平壌時間の設定をUTC+08:30からUTC+09:00に変更する。・平壌時間が設定されていた場合、韓国標準時に統合したうえで、平壌時間は削除する。
2015年~2018年の平壌時間を表現する必要があるので、(この件に限らず)過去のタイムゾーンは削除できないのでは。新元号になったからって平成を削除できるわけではないのと一緒で
ちょっと長い夏時間だったんだね、的な扱い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
またエンジニアの屍の山が築かれる (スコア:1)
「北朝鮮の朝鮮中央通信は30日、最高人民会議常任委員会が同日、北朝鮮の標準時間を30分早める政令を採択し、 [huffingtonpost.jp]
5月5日から適用すると報じた。」
発表から切り替え実行まで1週間しかないなんて、リアルタイムクロックが組み込まれたハードウェア、
それをもとに動くソフトウェア、ネットワークでつながったそういった装置間での、
時間の切り替えタイミングのずれなどで問題が起きないか、1週間でチェックさせられる向こうの国のエンジニア達に同情する。
まったく、独裁者の居る国ってのはこうだから…。
Re:またエンジニアの屍の山が築かれる (スコア:2)
その機能が有って、かつ、それで済むシステムなら「タイムゾーンをソウルにする」ところが続出する気が
Re: (スコア:0)
どこかの国は元号対応まで2ヶ月も猶予があるからな,なんてエンジニアに優しい国なんだ.
Re: (スコア:0)
元号が変わるというのはずっと前から分かっていて、具体的な名前が決まるのがギリギリというだけなら、
ソフトウェア的には、いかようにも準備のしようがあるのではないか?
そっちのほうは、カレンダーなどむしろアナログの業種のほうが大変だろうな。
印刷所のキャパってものがあるだろうし。
Re: (スコア:0)
そう、むしろ今回の改元の方が異例なんだよね
本来、改元はいつ起こるか分からない前提で対応するべきもの
ギリギリで提示した方がいい
Re: (スコア:0)
2000年が来るというのは(人類滅亡でもしない限り)確実にわかっていて、しかもギリギリまで仕様が決まらないような要素もなかったわけだが
Re: (スコア:0)
だからちゃんと準備できたじゃないか。
Re: (スコア:0)
こういうバカが「準備期間なんかいらない」とか言い出したのか
Re: (スコア:0)
まさか準備したいから1年ぐらい時間止まって欲しいとか思ってんの?!
Re: (スコア:0)
ウケるよねw
Re: (スコア:0)
元号はいつ変わるかわからないのだから「未来の日付に対してDateTime.ParseExact()してはならない」ってことだぞ。しかも未来ってのは開発時点より未来だ。ユーザーが入力するような、内容を制御できないものについては言うまでもなく使えない。
バージョン1803ではたまたまそれが表面化しただけなのに、結局MSがエラーにしないよう修正して尻拭いする羽目になったんだから、世間の程度はお察しだ。
Re: (スコア:0)
いや、もともと8.5時間ずれに対応できなかった現状承認じゃね。
屍の山が築かれないようにという独裁者の優しさだよ、これはw
Re: (スコア:0)
国防レーダーが電力不足で動いていない国で、時間がずれたからって、なんの問題になるだろう。
Re: (スコア:0)
日時計の据え付け角度をπ/24rad程修正する必要がある。
無論機械式時計でも長針をπrad進める補正が必要。
Re: (スコア:0)
その切替の時間帯を計画停電にすれば良いんじゃねぇ。
要は独裁者の国家なら発想の転換でいくらでも解決できる
Re: (スコア:0)
Windowsの場合、8.5時間時差(平壌時間)導入時に専用のタイムゾーン「UTC+08:30 平壌」を追加する対応を取っていました。
https://support.microsoft.com/en-us/help/3093503/ [microsoft.com]
今回の変更で時差が元に戻った場合、このタイムゾーンはどうなるんでしょうか。
タイムゾーンの追加や変更はちょくちょくあっても、削除はあまり見たことがないので、ちょっと気になります。
・平壌時間の設定をUTC+08:30からUTC+09:00に変更する。
・平壌時間が設定されていた場合、韓国標準時に統合したうえで、平壌時間は削除する。
Re:またエンジニアの屍の山が築かれる (スコア:1)
2015年~2018年の平壌時間を表現する必要があるので、(この件に限らず)過去のタイムゾーンは削除できないのでは。新元号になったからって平成を削除できるわけではないのと一緒で
Re: (スコア:0)
ちょっと長い夏時間だったんだね、的な扱い。