アカウント名:
パスワード:
日本だけしか使わないシステムだと、サーバ側のOSや、DBのTimezone がJST固定で、 APIに渡すタイムスタンプもJST が前提とかそういうシステムどっさりかと思います。
/search.action?start=201808010700&end=201808020000 = JST
こんな api 、どこでもありますよね・・。まぁとんでもないことになりますね。
クラウドは仮想化ホストを使っているケースが多いがゲストマシンは再起動でマシンがあがるまで、ハイパーバイザから時刻をもらう
ハイパーバイザの時刻は運用上変えれない全配下のゲストに影響する可能性があるから
つまりゲストは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がローカルタイムになります。そしてオンプレミスで過去を引き継いでるシステムだとローカルタイムなままの機器が有るのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
JST前提のAPI・・ (スコア:1)
日本だけしか使わないシステムだと、
サーバ側のOSや、DBのTimezone がJST固定で、 APIに渡すタイムスタンプもJST が前提とか
そういうシステムどっさりかと思います。
/search.action?start=201808010700&end=201808020000 = JST
こんな api 、どこでもありますよね・・。まぁとんでもないことになりますね。
Re:JST前提のAPI・・仮想化技術の時刻同期 (スコア:0)
クラウドは仮想化ホストを使っているケースが多いが
ゲストマシンは再起動でマシンがあがるまで、ハイパーバイザから時刻をもらう
ハイパーバイザの時刻は運用上変えれない
全配下のゲストに影響する可能性があるから
つまりゲストはos起動時少しの間二時間ずれる
そういった時刻の先祖がえりが再起動の度に発生するのではないか?
Re: (スコア:0)
時刻をJSTで配布するようなハイパーバイザなんてある?
Re: (スコア:0)
RTCがローカルタイム(JST)か、UTCか選択可能だったりするとヤバい
Re:JST前提のAPI・・仮想化技術の時刻同期 (スコア:0)
たとえば、GCPやAWSでRTCに全部のロケーションで別々のローカルタイムを
使ってるんじゃないかって話をしてるの?
us-west-1 us-central-1 us-east-1 asia-northeast1・・・その他全部が
それぞれ別の時刻で動いてるって?
移動して再起動したら時刻狂っちゃうし、んなわけないでしょw
最初にゲスト作ったときのタイムゾーンは
(たぶんホストの設定引き継いで)UTCだよ。
オンプレならホストJSTで合わせる頭おかしいのもいるかもしれないが
それは設定ミスでしょ
ゲストでJSTにすれば良いだけの話
Re: (スコア:0)
WindowsってレジストリいじらないとRTCがローカルタイムになります。
そしてオンプレミスで過去を引き継いでるシステムだとローカルタイムなままの機器が有るのです。