[特設]サマータイム対応相談室
■ このスレッドは過去ログ倉庫に格納されています
XP搭載パソコンなんですが、そのままで
サマータイムに対応するのでしょうか?
時刻合わせはNTPサーバーを使用しています。 RTCのウェイク時間もごまかさなければならない
組み込みでプログラムサイズが増えてROMやRAMからはみ出したりする場合もあるだろうな
ソフトウエア対応では無理ですよというパターンもありうるw
マジくるってるw お客様に、なぜサマータイムに対応してないのかと恫喝されています。そのぐらいの変更は織り込んでおくべきだろうと。
一方、ぼくのトレーナーは、入社時から、
"You ain't gonna need it"と、繰り返しておりました。
ぼくはどうしたら良いのでしょうか? 最初に合意した仕様に書いていないものは有償対応ですって言えばいい
"You ain't gonna need it" これが正解 >>7
お客様からそのようなご指示がなかったもので
で終わり
お客様の想定されないことは私どもも想定できません
ご指示があったのであれば別の見積もりを提案させていただいていたかと 「サマータイム実施は不可能」スライドが話題 「経済被害が兆単位」「サイバーテロをお膳立て」立命大・上原教授が指摘
http://www.itmedia.co.jp/news/articles/1808/10/news090.html
サマータイム導入で「電波時計が狂う」? メーカーに聞いた
http://www.itmedia.co.jp/news/articles/1808/09/news094.html
アホ↓
「サマータイム導入はコンピュータシステム的に難あり」は本当か 宮脇 睦
https://www.mag2.com/p/news/367461 👀
Rock54: Caution(BBR-MD5:7bff9ed63942b4cd01610d20b2c06e65) 農業系システムは日の出時間・日の入り時間を用いた積算あるからな。嫌がるだろうな サマータイム導入に数年と膨大なカネがかかるのは
IT業界なら素人でもわかるのに、
本当にIT業界じゃないプロはあほやなー 普通のシステムだったら
このスレにいるようなドカタどもにとっては
タイムゾーンをJSTにすれば勝手にかわるから一切影響ない
困るのは日時をUTC基準の通算値で保存してない知恵遅れシステムぐらいなのは
簡単に予見できる サマータイムをあらかじめ用意出来て無いのは一般企業システムがほとんどだろうな
そこら辺、かなりの負荷になるだろう
サマータイム導入で一般中小企業は淘汰されるだろうね 時計を動かすってのは非合理だと思うけどね
都合が良くなるのは些細なことでその為に不用なリスクを負うなんて愚の骨頂でしょ
プログラムに関わっている人なら分かるはずだ オリンピックのための一時的な措置だけど
そもそもオリンピックの競技時間はUTCの時間で行われるので
サマータイム導入しても意味ないんだよね
原発とか航空機とか電車とかそういうインフラが心配 実は多い! サマータイムをやめた国々
サマータイムを実施した結果、社会に混乱を招くことになったり、不評だったりして撤回した経験を持つ国は多い。
アイスランド、アゼルバイジャン、イラク、コロンビア、トルコ、フィリピン、モンゴル、ロシア、韓国、中国などがそうだ。
アメリカやカナダ、オーストラリアでは、一部の州で撤廃されている。
ちなみに、日本から近い東南アジアの国々は、赤道直下に位置し、1年を通して昼と夜の長さに大きな違いがないため、導入されたことがない。
https://taishu.jp/articles/-/57456?page=3 タイムゾーンを考慮したシステムなら、OSが対応したのち、
TZをJSTからJDTに変えるだけなんだろうけどね
ローカル時間が進んだり戻ったりするだけで、いろいろトラブりそうだよね 「サマータイム導入はコンピュータシステム的に難あり」は本当か
http://blogos.com/article/317015/
さて、サマータイムの導入の議論は、繰り返し現れては消えておりますが、その度に「懸念」されるのが、コンピュータシステムについてです。
果たして対応できるのか、社会は混乱しないか。
ハッキリ言って「アホ」と申し上げます。なぜか? だって私がプログラマーとして社会人になった平成元年から、ずっと議論されていたことだからです。
結論からいえば「大丈夫」。コンピュータシステムを知っていれば、さほど大騒ぎする事ではありません。むしろ、サマータイムを導入する最大の障壁は日本人の習性にあります。 >>22
どうせ広告があるんだろうから見に行く気はないが、
30年もプログラマやってて未だ理解できないってのは
どこまで頭が悪いんだろう?としか思えぬ。 >>22
考えることが少なく済んでて悩むことがあんまなさそう
大人になっても単純なままで生きていられてうらやましい限りだ 頭が悪いと幸せだよな
悩まないといけないことも悩まないで済むからね 誰もシステムの時刻を変更できないなんて言ってないんだけどな
変更したことによる影響の把握とその対応がこの準備期間じゃ無理って話で
コードにif文を追加することしか思いつかない時点でプロじゃなくてただの趣味グラマだろ ハッキリ言って「アホ」と申し上げます。
新たなパワーワード。 >>28
システムの時刻変更しちゃだめだよ。夏時間じゃなくなる。
アホ氏のパソコンならそれでもいいけど。 パソコンの時刻合わせなんて自動だろ?
クライアントOSを更新して日本のサマータイムに
対応すれば良いんじゃないのか?
それともNTPサーバーを更新すればいいだけなのか?
いずれにしろ事前に更新しておけばいいだろう
そういう仕組を取り入れてないなら、その日の朝来て
全台数、時間を変えればいいだろう。 >>32
サマータイムの対応できてないのは宮脇脳だからか?
どちらかと言えはアホなのはサマータイムに対応できてない宮脇だよな >>32
二時間ずらすサマータイムなんてのは、今の世界線にはない。
NTPはローカルタイムを送信してるわけではない。
NTPのプロトコルにずらす時間の情報はない。
OSの時刻管理の仕組みでも、夏タイムはフラグでしかない。
二時間ずらすなら全部改修が必要。
全台って今何台動いてるのか知ってるのか?
炊飯器にすらCPUもタイマーも入ってるんだぞ?
おじいちゃんの若い頃とは時代が違うんだよ。
なぜバカは分からないことに口を出すのか。 やっぱりアホしかおらんわ
システムの時刻なんか変更されない
日本の計算機をアメリカにもっててもドイツにもってても
計算機の時刻は同じ
世界中のどのntpサーバも同じ時刻を発信する
そうでないと時間が狂う
※ 変なntpサーバがいれば、そいつのせいで受信したクライントが全部狂う
じゃあ、オマエのPCに表示されてる日時はなんなの?
知恵遅れにはコレが理解できない
まず知恵遅れにはタイムゾーンという概念がない >>35
つまり、コンピュータはUTCで時刻を保持していて
タイムゾーンという時差情報を元に計算して
地域ごとの時刻を出力しているのですね? そしてソフトウェアは地域ごとの時刻で処理を行うから
サマータイム導入によって混乱が生じるということですね? 伝統的な計算機では、通常、
1970年01月01 00:00:00 (UTC)
からの通秒がその計算機の時刻になってる
その通秒をタイムゾーン分の秒数足して日時変換して出力してるだけだからな
2038年問題というの聞いたことあるだろ
コレは、その通秒が32bitの計算機ではオーバーフローする
こっちのほうがよほど深刻 >>36
> つまり、コンピュータはUTCで時刻を保持していて
そうとは限らない。OSや設定で変わってくる。
例えばWindowsはコンピュータは現地の時間に設定する
LinuxはUTCに設定してOSが時間を調整する
もちろんこれはデフォルトの挙動なだけで変更することは可能 >>39
それはUNIXエポックですよね
古いUNIXでOSを更新できないようなものだと
問題になりますね、でもそれってまだ先のことですよ
喫緊の課題はサマータイムです
そういうことですね? 例えば、日本なら
計算機の通秒に
540秒たして(UTC +09:00 → つまり 9 * 60秒)、
日時変換すれば日本の時刻になる
サマータイムならその足す秒数が変わるだけだからな
めっちゃしょうもない話
タイムゾーンの設定増やすだけー >>40
Windowsはハードウェアクロックに地域時間を設定するってことですか?
そういうことですね? >>42
変換方法のことですね
UTCから地域時刻に変換する方法が簡単だというわけですね? >>39
2038年問題はOSのレベルでは解決済み
(アプリレベルでは対応してないのがあるだろう)
日付を何ビットで扱うかの問題なので
32bitの計算器かどうかは関係ない OSレベルでは、POSIXのtime_tが32bitのままなら
なにも解決されてない
あいかわらず
クソニートはテキトーなことばっかりいうからな >>43
> Windowsはハードウェアクロックに地域時間を設定するってことですか?
デフォルトがそうなっているだけで変更できる
ハードウェアクロックがサマータイムに対応していることは無いと信じてるが
実際どうかはしらん。OSがサマータイムの時間の調整をしている OSが対応するもへったくれもない
クソニートはやっぱりテキトーなことばっかりいうわ
タイムゾーンの設定ふやすだけなのにな 一つだけわかるのはID:grOjVjUWが間違った知識を振りまいてる事
多分1999年辺りで知識が止まってるんだろうな ちなみにNTPでは
1970年01月01 00:00:00 (UTC)になってる
オリジンがちがうだけで全部仕組みなんか同じ ×1970年01月01 00:00:00 (UTC)
○1900年01月01 00:00:00 (UTC) > タイムゾーンの設定ふやすだけなのにな
設定を増やせない環境との共存。
手動でやらなければいけない環境もある。
増やすにしても、そのタイミングによって
外部システムとの連携で、お互いの時間が合わないことがある。
それがどれくらいあるのかを調べつくさなければいけない。
そう。消費税だってかける数字を1.05から1.08にするだけだったのだ
タイムゾーンを増やすにもシステムの改修に金がかかるので
国の補助が必要。国は仕事が遅いから、補助金出すまで時間がかかる データをUTCで保存しているシステムばかりじゃないからな。
JSTで保存していればサマータイムで時間が巻き戻ることになる
それがどれくらいあるのか。ぱっと出てこない ID:grOjVjUWが間違った知識の訂正
windowsの内部時計はtime_tではない
windows XP,7,8,8.1,10はまずPOSIXじゃない
windowsはUNIXのエポックタイムを使ってない
(1601年01月01日00時00分00秒)からの経過秒数)
RTC(ハードウェアクロック)は経過秒数ではなくそれぞれ何年何月何日何時何秒という情報を持っている
OSによってそれをUTCに換算するかローカルタイムにするか決定している
windowsはハードウェアクロックがローカルタイムだという判断なのでネットにつなげてなければ
場所を変更すると時刻がおかしくなる
どこにいても同じ時刻は指しはしない サマータイム
・サマータイムを開始するときに地域時刻で時刻のスキップがある
・サマータイムを終了するときに地域時刻で時刻の繰り返しがある
サマータイムの懸念点
・地域時刻で時刻の計算をしているとヤバイ
・地域時刻で処理を実行しているとヤバイ
タイムゾーンを増やすだけというのは何に対する解決策なんだろ
2038年問題も関係ないし
半角の人は何を解決しようとしてるんだろ 半角の人はどこかのスレを間違った知識でずっと荒らしてた人と同じ人なのかもしれない
馬鹿すぎて相手にされてなかった > windowsはハードウェアクロックがローカルタイムだという判断なのでネットにつなげてなければ
> 場所を変更すると時刻がおかしくなる
> どこにいても同じ時刻は指しはしない
コレが典型的な低学歴クソニートのオツム
ワロタ クソニートは概念的に同じことを
違うことと理解すらしいからな
そもそもクソニートはオツムに問題がある
クソニートである理由もよくわかる クソニートかどうかなんか
書き込みですぐに分かるからな 間違いを認めておとなしくしていればいいのに
だからお前はどこでも相手にされないんだよ
馬鹿 まちがってる?
ホンキでそんなこと思ってるわけか。。。
まあイロイロとしょうがないわ >>56みたいなシステムでは
そのシステムではサマータイムの設定にしなければ問題はおきない
ほらもう解決した WindowsのノートパソコンをUSBでUbuntu起動してシャットダウンしてWindowsに戻すと時間がUTCになってしまうんだぜ
デュアルブート環境だと今でも混乱する >>65
時刻はユーザが絡むところだからシステムの都合だけ
で設定しませんというのはできるんかね? 難しいのじゃないかな
非現実的な解決策で良いなら国民全員が政府を無視すればええと思うんよ
クーデターや >>39
伝統的な計算機といえば汎用機だろ。
汎用機のエポックは1970年じゃないぞ。 考え方はユリウス通日から
グレゴリウス暦や和暦や曜日に変換するのと同じだからな
これからのシステムはユリウス通ナノ秒ぐらいまで対応したほうがいい 5chのあちこちでサマータイムにちゃんと対応しない場合に
工場で火事になったりするかもしれないとか書いてたけど
それをまとめたような記事がライブドアニュースに乗ってる スタンドアロンのコンピュータの時刻のことしか考えてないという点では例のあの記事を書いたやつと同レベルだな。 むしろ、ネットワーク上に処理で必要となるプロトコルのなかにローカル時刻なんか埋め込むような
知恵遅れの顔を見たいわ
ローカル時刻なんか計算機の時刻を変換して表示されるただの文字だからな
何度もいうが、計算機の時刻は日本からアメリカにもっていっても同じ
スタンダアローンとかそんなもん関係ない
基本的に低学歴知恵遅れは計算機が時刻をどうやって表示してるか分かってない
地域の時刻なんかただのしょうもないローカライズの問題 >>74
上のレスを見る限り、冗談抜きでマジで本人な気がしてきたw
画面に表示される時刻のことしか見えてない視野の狭さがまるで同じだ 低学歴知恵遅れは
計算機の時刻変更すると思ってるのか
なるほどな こんだけ頭悪いと生きてくのがつらそうだと
ほんとそう思うわ
コタエ全部書いてやってるのに そもそも
低学歴知恵遅れが技術板にいること自体がおかしからな なにも理解できてない低学歴知恵遅れが
サマータイムで騒いでるのだけは分かったわ >>73
日本がサマータイムで2時間ずらすのと同時に世界的に全部ずれるんだったらいいかもしれないけど、現実は違うわけだし
そもそも時計の表示だけじゃなくて、業務フロー自体がサマータイムを考慮されてないんだから、
コンピューターシステムだけの問題じゃなくてトラブル多発だと思うぞ
工場だって火事になるかもしれないというのはその通りだよ。JST=UTC+9:00という大前提でいろんなものは組まれてるわけだから
当然業務フローにサマータイムが考慮されてないんだから、業務システムだってサマータイムをTZを追加するとかいう雑な方法で
無理やり導入しても依存関係がめちゃくちゃに破壊されてるから動くわけがないと思うけど。 そういう低学歴知恵遅れドカタが作ったシステムは
2時間時差があるまま運用すればおしまい
それが低学歴知恵遅れドカタのシステム それでなにが困るわけ?
なにも困ることないでしょ
低学歴知恵遅れドカタが作ったシステムは動きさえすれば
問題ないハズ >>84-85
「2時間時差があるまま運用」することで「動きさえ」もしないのがわからないのかな どういう作りにしてるから動かなくなるの?
いちいち池沼がどういうウンコな作りにしてるかまで
知ったこっちゃないからな >>87
客がこういう感じになるんだよな。
で、動かないとタダで治せ等と言い出す。
損害賠償は森や遠藤に回すようにしないと、
この国本当におかしくなるぞ。 >>87
> どういう作りにしてるから動かなくなるの?
うるう秒で動かななったときは、
たった1秒の時間の違いで動かなくなる作りだったよ >>87
海外支社のサーバーでバッチAが実行された後にその結果を利用して東京本社でバッチBが実行されるというような組み方なら、
サマータイムで前後が入れ替わるのはどう考えてもNGだろ。じゃあバッチAを早めるかバッチBを遅くするかってことになるけど、
タイミングが始業、終業時間などに関連していたらそういうわけにもいかないだろう
物流だって国内の物流はサマータイムで2時間まるまる早めにずらすことはできるかもしれないけど、
国際線はそうはいかないだろうから輸送計画の組み直しが一斉に発生して現場でトラブルが発生しやすくなり
遅配の原因になるだろうな
「池沼がウンコな作り」にしてるのは業務システムだけじゃなくて業務フローそのものにもあるんだよ。 トラックの運ちゃんが、明日はサマータイムですが
配達にかかる時間は同じなので、一時間遅れます。
が許されるかどうか
荷物が到着する時間が遅れるだけで
大問題だろう 普通に考えてまともなシステムなら営業時間帯の年間テーブルぐらいもってるハズだからな
システムはそれに従って動作する
当然これは期末までに関係ある全部署が入力しておかないといけない
その妥当性の検査・検証するのもその部署だからな
営業時間帯、サービス時間帯の規定がないのがそもそもおかしい
最低でも外向けにサービスするシステムならその規定ができないシステムとかありえないからな
入力になる時間帯なんかシステムにとっては決めの問題
トラックの運ちゃんにとっても同じく決めの問題
で、バッチなら起動条件がないバッチなんかないからな
普通なら依存関係があってこのバッチが正常終了しないとこのバッチは起動できないとか
ジョブスケジュラーに条件がついてる
どんなゴミシステムでもこれぐらいのことやってると思うわ
知恵遅れのシステムでは時間になったら起動するだけの頭悪い作りなのは分かったわ
そして限界時間ギリギリまで処理が終わらない池沼システムなのもわかった
コレがザ・池沼システムというのがよく分かったわ まあそういうことだよね 時刻を基準にして諸々組み立ててあるのにそれを変えるってのは相当なことよ
総点検を伴うんだからそれに見合う効果が見込める場合にしかしちゃいかんよね
テキトーに経済効果が云々言ってるけどそれ始業を早くすればできるから
それは好きにすればいいよ 制度を変えてオレスゲーやりたいだけなら迷惑だっちゅうことね 結局の所サマータイムに対応していないシステムが
どれくらいあってそのような修正が必要化を洗い出す
時間がすごくかかるってことなんだよね。
なんたってサマータイムに対応しているかなんて保証は
今のシステム全てにないんだし .>>92
営業時間帯内のはじめの方に海外からのバッチ処理がされる前提だったら、
海外から見たら営業時間がずれるわけだから海外のフローか国内のフローを調整する必要があるだろ
起動条件があるバッチなら大丈夫、と言うが、起動条件に引っかかって毎回起動できないバッチがあったら
大丈夫でもなんでもないだろう、毎日動かないのだから
世界中のシステムと多く連携していたらどのバッチが問題があって、そのバッチを動かすために
起動条件を変えて業務フローを変えなきゃいけないんだろうから
本当の基幹システムはその辺タイムゾーン入れ替えたら動くようになってると思うけど、
JDTへの対応が異なる基幹システム間と連携しながら動く周辺システムに
関しては、業務フロー変更を前提としたシステム改修が必要だと思うが。 >>92
その「ハズ」をテストするコストをどうすんだっつってんだよバカ
それが分からないからお前が低学歴ヒキニートなのがバレバレなんだが
可哀想だからみんな指摘してないだけなのに なんでこんなあほなことしたかねえ
開催時期を10月にずらすだけでいいのに 未だにサマータイムってなんだか解らない
開始や終了時刻を変えるだけでは駄目なのか?
状態が同じなのに余計な事を増やすのは複雑さが増していくだけ
というのが解らず
難しい事を上手くやって
俺スゲー
ってやってるようにしか見えないんだけど
日本の無駄ってこんな感じの物が多い
わざと複雑にして非効率になってる
けどそれが出来る事が素晴らしい
って扱いになってる
異常です 業務システムに限らずtoCなWebサービスだって、データの登録順がクリティカルな意味を持つ時にそれを時刻で比較してたら詰むからな。シーケンス化にするなりなんなりしないといけない。
他にも入力された日付時刻のバリデーションとか、
セレクトボックスで時刻を選ぶようなUIがあったら存在しなくなる時刻と二回やってくる時刻をどうするかとか、
直さなくちゃいけないところは一瞬でいくらでも浮かぶ。
どんなにしっかり作ってあるシステムでも、日本国内で使う前提で日本人が作ってたらサマータイムなんて想定されてないわ。 >>1
意見具申
猛暑対策なら新築の居宅は「白い屋根」(含む薄いグレー)を義務化すれば良いんじゃね?
ソーラーパネルや太陽熱温水器以外の「黒い屋根」の居宅は新築禁止って事で ■ このスレッドは過去ログ倉庫に格納されています