アカウント名:
パスワード:
日本だけしか使わないシステムだと、サーバ側のOSや、DBのTimezone がJST固定で、 APIに渡すタイムスタンプもJST が前提とかそういうシステムどっさりかと思います。
/search.action?start=201808010700&end=201808020000 = JST
こんな api 、どこでもありますよね・・。まぁとんでもないことになりますね。
PCの時刻同期使ってる場合はどうなるんだろうかあと、電波時計なんかはどうなるんだろうか
PCの時間同期は問題ないです。内部がUTCになってる。
電波時計は1時間なら対応してるけど2時間になると自動的に動くかどうか…
いやー、日本だとPCの内蔵時計はlocaltimeにする(で、UTCとのずれは固定という前提を置いた運用)のが一般的で、時刻同期もNTPで降りてきた時間をlocaltimeに変換してから時計に設定(これ自体は内蔵時計のタイムゾーンがわかっていれば矛盾はない)してますよ。
Linux/UNIXの眷属だとインストーラが内蔵時計をUTCにするかlocaltimeにするか選択する画面を持ってます。その辺のサーバ運用教科書だと大抵「localtimeにしといた方がいいですよ」って書いてある。
お手元のPCのBIOSセットアップ画面で内蔵時計の時刻をご覧になるとよいのでは。
それはマザーボード上のハードウェアクロック(RTC)をUTCにするかローカルタイムにするかの設定です。ですのでOS内部では常にUTCで扱われています。
影響するのはRTCを読み込む再起動時になります。
電波時計については、NICTのページに標準電波の仕様が書いてあります。
なんと、タイムコードとしてlocaltimeを放送してます。
で、予備ビットに「これを夏時間情報として用いる場合には」と留保が書いてあります。
時計屋さんがこれを「実施されうるもの」と解釈して実装していれば、「夏時間実施中」への遷移とともにタイムコードが進んだり戻ったりするので、時計は頑張って時刻合わせをする、の、かな。
「場合には」だから決まるまでわかんないじゃん、と解釈すれば、タイムコードだけに着目して、大幅にずれた時間が下りてきたら普通に頑張って時刻合わせが始まる、の、かな。
電波時計でもそうじゃなくてもだけど、タイムカードと勤務時間の関係とかも調整時刻をまたいであ勤務してる人の扱いとかどうするってなるよね。
開始日は少なくしか勤務してないのに終了時間を早く迎えるし、終了日は同じ時刻を2回超えてるから、タイムカードは8時間なのに実際は10時間勤務。
サマータイム導入してる国ってどうしてんの?これ。
サマータイムで日本中の電波時計がゴミになる(かも)という話 [mzsm.me]
要約すると、 ・電波時計の信号にサマータイムの仕様はあるが、2時間のずれには対応してない ・そもそもサマータイムの仕様自体が予備なので実装されてない電波時計も多いかも。つまり1時間のサマータイムでも実施すれば使えなくなる電波時計はある ・標準電波の時刻表期自体を2時間ずらせばいんじゃね? → セキュリティ上の理由で時刻を標準電波から取得してるスタンドアロンのシステムが結構ある。これらは標準電波はUTC+9という仕様に従って作られてる。標準電波が突然UTC+11になったら不具合を起こすかも
この話が広まったらさすがに「51%が賛成」なんてことにはならないと思う。
標準電波と電気時計 [srad.jp](電気設備学会誌 / 31 巻 (2011) 11 号)
この最後の部分に、絶望的なことが書かれている。2時間ではなく1時間のサマータイムが導入された場合でも、既存の電波時計には対応出来ない物が出る。
標準電波のタイムコード仕様には,運用開始当初から予備ビットとして「夏時間」情報が2ビット割り当てられていた。これは,サマータイム切り替わりの予告や現在の状態を知らせる意味は明白であるが,「時刻」の部分に関しては,電波時計のメーカ間において解釈の違い
URL部分がエラーになって、スラドへのリンクになってしまってました。ごめんなさい。標準電波と電気時計 [jst.go.jp](電気設備学会誌 / 31 巻 (2011) 11 号)
手元の電波時計で試してみた人によると [twitter.com]、実際には受信してから時刻表示が盛大に壊れたようで。どうやったらこんなことが起こせるのかは謎だけど…、シチズンの時計でこうなるくらいならもうどうなるんだか…。
このトピックに、「参考になる」のモデレートをお願いします > モデレータ各位
手元の電波時計だと、1時間に1回電波受信するタイプか、1日に1回電波受信するタイプ。1日に1回受信するタイプだと午前2時のやつと午前0時のやつの2種類がある。電波時計によってはサマータイム補正がかかるのは26時間後。
もちろん、電波状況が悪い場所や送信所から遠方だと天候によっても受信できないことがあるので、電波時計といえども、サマータイムの開始終了時に手動時刻合わせは必要。
同期時刻も問題だけど、それ以前きちんと受信した電波でサマータイムに合わせた時刻設定ができない機種が大量にあるでしょ。
クラウドは仮想化ホストを使っているケースが多いがゲストマシンは再起動でマシンがあがるまで、ハイパーバイザから時刻をもらう
ハイパーバイザの時刻は運用上変えれない全配下のゲストに影響する可能性があるから
つまりゲストはos起動時少しの間二時間ずれるそういった時刻の先祖がえりが再起動の度に発生するのではないか?
時刻をJSTで配布するようなハイパーバイザなんてある?
RTCがローカルタイム(JST)か、UTCか選択可能だったりするとヤバい
たとえば、GCPやAWSでRTCに全部のロケーションで別々のローカルタイムを使ってるんじゃないかって話をしてるの?
us-west-1 us-central-1 us-east-1 asia-northeast1・・・その他全部がそれぞれ別の時刻で動いてるって?移動して再起動したら時刻狂っちゃうし、んなわけないでしょw
最初にゲスト作ったときのタイムゾーンは(たぶんホストの設定引き継いで)UTCだよ。
オンプレならホストJSTで合わせる頭おかしいのもいるかもしれないがそれは設定ミスでしょゲストでJSTにすれば良いだけの話
WindowsってレジストリいじらないとRTCがローカルタイムになります。そしてオンプレミスで過去を引き継いでるシステムだとローカルタイムなままの機器が有るのです。
自分でJST換算してるなら夏時間適用期間もJST使うから問題は少ないOSのローカルタイムを取得してるならシステムが夏時間を使わないように設定しないとおかしな動きをするかも
それは今からISO8601に書き換えてもばちは当たらない。
海外含め、サマータイム対応しているつもりのシステムも、1時間のサマータイムにしか対応してませんでしたって事がありそう。ロード・ハウ島ってところが30分のサマータイムらしいので、柔軟に設定できるシステムもあるとは思うが、「そんな島は未対応でもいいや」って1時間固定とかやってるものもある気がする。
あとありそうなのは、複数のシステムで2重3重に対応してしまって4時間、6時間とずらしてしまうとか・・・
しかも、テーブル定義が、
START_DATE_TIME VARCHAR2(12), -- ex 201808010700/JST固定END_DATE_TIME VARCHAR2(12), -- ex 201808020000/JST固定
だったりするわけですね。
OSとかDBは、UTCで実装されていますので、サマータイム変更時でも、正確なローカルタイムを返すでしょうから、現時刻とかの差分を計算する処理なんかあったら、結構すごいことになりそうですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
JST前提のAPI・・ (スコア:1)
日本だけしか使わないシステムだと、
サーバ側のOSや、DBのTimezone がJST固定で、 APIに渡すタイムスタンプもJST が前提とか
そういうシステムどっさりかと思います。
/search.action?start=201808010700&end=201808020000 = JST
こんな api 、どこでもありますよね・・。まぁとんでもないことになりますね。
Re: (スコア:0)
PCの時刻同期使ってる場合はどうなるんだろうか
あと、電波時計なんかはどうなるんだろうか
Re:JST前提のAPI・・ (スコア:1)
PCの時間同期は問題ないです。内部がUTCになってる。
電波時計は1時間なら対応してるけど2時間になると自動的に動くかどうか…
Re:JST前提のAPI・・ (スコア:2)
いやー、日本だとPCの内蔵時計はlocaltimeにする(で、UTCとのずれは固定という前提を置いた運用)のが一般的で、時刻同期もNTPで降りてきた時間をlocaltimeに変換してから時計に設定(これ自体は内蔵時計のタイムゾーンがわかっていれば矛盾はない)してますよ。
Linux/UNIXの眷属だとインストーラが内蔵時計をUTCにするかlocaltimeにするか選択する画面を持ってます。その辺のサーバ運用教科書だと大抵「localtimeにしといた方がいいですよ」って書いてある。
お手元のPCのBIOSセットアップ画面で内蔵時計の時刻をご覧になるとよいのでは。
Re: (スコア:0)
それはマザーボード上のハードウェアクロック(RTC)を
UTCにするかローカルタイムにするかの設定です。
ですのでOS内部では常にUTCで扱われています。
影響するのはRTCを読み込む再起動時になります。
Re:JST前提のAPI・・ (スコア:2)
電波時計については、NICTのページに標準電波の仕様が書いてあります。
なんと、タイムコードとしてlocaltimeを放送してます。
で、予備ビットに「これを夏時間情報として用いる場合には」と留保が書いてあります。
時計屋さんがこれを「実施されうるもの」と解釈して実装していれば、「夏時間実施中」への遷移とともにタイムコードが進んだり戻ったりするので、時計は頑張って時刻合わせをする、の、かな。
「場合には」だから決まるまでわかんないじゃん、と解釈すれば、タイムコードだけに着目して、大幅にずれた時間が下りてきたら普通に頑張って時刻合わせが始まる、の、かな。
Re:JST前提のAPI・・ (スコア:1)
そして実際の時計は3時間進んで大惨事になる
Re: (スコア:0)
電波時計でもそうじゃなくてもだけど、
タイムカードと勤務時間の関係とかも調整時刻をまたいであ勤務してる人の扱いとかどうするってなるよね。
開始日は少なくしか勤務してないのに終了時間を早く迎えるし、
終了日は同じ時刻を2回超えてるから、タイムカードは8時間なのに実際は10時間勤務。
サマータイム導入してる国ってどうしてんの?これ。
Re:JST前提のAPI・・ (スコア:1)
サマータイムで日本中の電波時計がゴミになる(かも)という話 [mzsm.me]
要約すると、
・電波時計の信号にサマータイムの仕様はあるが、2時間のずれには対応してない
・そもそもサマータイムの仕様自体が予備なので実装されてない電波時計も多いかも。つまり1時間のサマータイムでも実施すれば使えなくなる電波時計はある
・標準電波の時刻表期自体を2時間ずらせばいんじゃね? → セキュリティ上の理由で時刻を標準電波から取得してるスタンドアロンのシステムが結構ある。これらは標準電波はUTC+9という仕様に従って作られてる。標準電波が突然UTC+11になったら不具合を起こすかも
この話が広まったらさすがに「51%が賛成」なんてことにはならないと思う。
Re: (スコア:0)
標準電波と電気時計 [srad.jp](電気設備学会誌 / 31 巻 (2011) 11 号)
この最後の部分に、絶望的なことが書かれている。
2時間ではなく1時間のサマータイムが導入された場合でも、既存の電波時計には対応出来ない物が出る。
標準電波のタイムコード仕様には,運用開始当初から予備ビットとして「夏時間」情報が2ビット割り当てられていた。これは,サマータイム切り替わりの予告や現在の状態を知らせる意味は明白であるが,「時刻」の部分に関しては,電波時計のメーカ間において解釈の違い
Re: (スコア:0)
URL部分がエラーになって、スラドへのリンクになってしまってました。ごめんなさい。
標準電波と電気時計 [jst.go.jp](電気設備学会誌 / 31 巻 (2011) 11 号)
Re: (スコア:0)
手元の電波時計で試してみた人によると [twitter.com]、実際には受信してから時刻表示が盛大に壊れたようで。
どうやったらこんなことが起こせるのかは謎だけど…、シチズンの時計でこうなるくらいならもうどうなるんだか…。
Re: (スコア:0)
このトピックに、「参考になる」のモデレートをお願いします > モデレータ各位
Re: (スコア:0)
手元の電波時計だと、1時間に1回電波受信するタイプか、1日に1回電波受信するタイプ。
1日に1回受信するタイプだと午前2時のやつと午前0時のやつの2種類がある。
電波時計によってはサマータイム補正がかかるのは26時間後。
もちろん、電波状況が悪い場所や送信所から遠方だと天候によっても受信できないことがあるので、
電波時計といえども、サマータイムの開始終了時に手動時刻合わせは必要。
Re: (スコア:0)
同期時刻も問題だけど、それ以前きちんと受信した電波でサマータイムに合わせた時刻設定ができない機種が大量にあるでしょ。
Re:JST前提のAPI・・仮想化技術の時刻同期 (スコア:0)
クラウドは仮想化ホストを使っているケースが多いが
ゲストマシンは再起動でマシンがあがるまで、ハイパーバイザから時刻をもらう
ハイパーバイザの時刻は運用上変えれない
全配下のゲストに影響する可能性があるから
つまりゲストはos起動時少しの間二時間ずれる
そういった時刻の先祖がえりが再起動の度に発生するのではないか?
Re: (スコア:0)
時刻をJSTで配布するようなハイパーバイザなんてある?
Re: (スコア:0)
RTCがローカルタイム(JST)か、UTCか選択可能だったりするとヤバい
Re: (スコア:0)
たとえば、GCPやAWSでRTCに全部のロケーションで別々のローカルタイムを
使ってるんじゃないかって話をしてるの?
us-west-1 us-central-1 us-east-1 asia-northeast1・・・その他全部が
それぞれ別の時刻で動いてるって?
移動して再起動したら時刻狂っちゃうし、んなわけないでしょw
最初にゲスト作ったときのタイムゾーンは
(たぶんホストの設定引き継いで)UTCだよ。
オンプレならホストJSTで合わせる頭おかしいのもいるかもしれないが
それは設定ミスでしょ
ゲストでJSTにすれば良いだけの話
Re: (スコア:0)
WindowsってレジストリいじらないとRTCがローカルタイムになります。
そしてオンプレミスで過去を引き継いでるシステムだとローカルタイムなままの機器が有るのです。
Re: (スコア:0)
自分でJST換算してるなら夏時間適用期間もJST使うから問題は少ない
OSのローカルタイムを取得してるならシステムが夏時間を使わないように設定しないとおかしな動きをするかも
Re: (スコア:0)
それは今からISO8601に書き換えてもばちは当たらない。
Re: (スコア:0)
海外含め、サマータイム対応しているつもりのシステムも、1時間のサマータイムにしか対応してませんでしたって事がありそう。
ロード・ハウ島ってところが30分のサマータイムらしいので、柔軟に設定できるシステムもあるとは思うが、
「そんな島は未対応でもいいや」って1時間固定とかやってるものもある気がする。
あとありそうなのは、複数のシステムで2重3重に対応してしまって4時間、6時間とずらしてしまうとか・・・
Re: (スコア:0)
しかも、テーブル定義が、
START_DATE_TIME VARCHAR2(12), -- ex 201808010700/JST固定
END_DATE_TIME VARCHAR2(12), -- ex 201808020000/JST固定
だったりするわけですね。
OSとかDBは、UTCで実装されていますので、サマータイム変更時でも、正確なローカルタイムを返すでしょうから、現時刻とかの差分を計算する処理なんかあったら、結構すごいことになりそうですね。