  |
はてなキーワード: 日本標準時とは
高校生の頃から登山をしてきた人間として、妥協的解決方法を挙げる。
子供が生まれてからは子供と一緒に行ける日帰り低山しか行かなくなった。低山は人が少ない分、道迷いのリスクはあるが、GPSが発達してきてそのリスクは大分減った。
もちろん、事前の地図読みと、上りの際の分岐確認は写真をとりながらチェック。登山口と下山口が異なる縦走などは極力避けている。
あと、日帰りだと、荒天時はそもそも行かなくなるので、さらにトラブルは少なくなる。
ただ、登山を始めたころは、高い山、有名な山にどうしても登りたくなる。
実際、有名で、沢山の登山者がいる北アルプスの表銀座だって、自分が歩いてきた稜線が円弧を描くように空中に伸びている景色は、自分の体の小ささと、それにもかかわらず、歩き続けられた自分の足の強さを同時に実感できる。
南アルプスの北岳からみた富士山は、山と山のあいだの空気の厚み、上空から地上までの空気の重なりを、青色のグラデーションが教えてくれる、絶景中の絶景だ。
とりあえずの必須条件として、子供用GPSを持たせることと、計画書の提出（所轄の警察と家庭用）から初めてはどうだろうか。
子供用GPSは位置情報を携帯電話のパケットでサーバーに定期的に送る機器だ。電池が長持ちし、自ら電源を切ることができない。保護者（妻）は数分ごとに地図で場所を確認できる。ここ数年で商品が増えた。
主な登山道なら、ほぼ携帯電話の圏内だ。音声メッセージを送ることもできる。月額700円くらいだ。
計画書は登山者のためでもある。ガイドブックを参考にしながらでもいいし、地図を見ながらでもいい。日帰りでも、行動の節目節目で計画した時間通りでなければ、引き返すきっかけになる。
どうしても、日本アルプスなど高山に登りたいなら、小屋泊まりをやめることから提案しよう。１日の行動時間や距離が長くなりがちだし、何かあったときの装備が貧弱になりがち。ウルトラライトは一見機能的だが、トラブルには弱い。あれは体力も経歴も十分な人がやる事だ。
あと、バリエーションルートもだめだ。滑落しやすい場所もふえるし、トラブル時に他人の目がない。登山道も迷いやすい。テントは災害時にも有用だ。（これは山好きが道具を買ったときに家族にする言い訳の典型だが。）
テント泊で夜明け前（夏場なら４時くらい）に歩き出し、10時か11時にはテン場に到着、あとは食事して夕方に寝るような計画にすれば、行動範囲は狭くなるが夕方の道迷いや午後の荒天に遭いにくい。
ご主人は、休みがとれるみたいなので、予備日は必須。焦らないで日程をこなせるようにしよう。自分は雨の日の停滞が意外と好きだった。
あと、冬は絶対ダメ。あと、秋も日が早いから要注意。8月の日照時間は、5月のそれとほとんど変わらない。道迷いは夕方におきる。
さらに、ご主人は、高尾山からスタートだということなので、首都圏在住だと思われるが、関東から東の山は早く日が暮れる（日本標準時で比較した西日本と比べて）。低山で練習したくなる時期の、ちょっと涼しくなる9月は、昼過ぎには登山口に帰るくらいの気持ちでないと危ない。
——————————————————————————————
告
5/15
「科学哲学第二」のレポートは、5/31 までに１号館１階の浅川の レターボックスに提出すること。
——————————————————————————————
告
6/3
期限を過ぎて提出されたレポートは、いかなる理由があろうとも 受けつけません。
締切を過ぎてもまだ私のレターボックスに「科 学哲学第二」のレポートを入れる者が居ますが、5/31 の午後 5:00 以降に投函されたレポートは全て破棄しました。
——————————————————————————————
告
6/4
「5/31 まで」と書いたら「5/31 の午後 5:00 まで」の意味です。
こんなことは社会常識です。
——————————————————————————————
告
6/5
他の教官が午後 12:00 まで受けつけていても、関係ありません。
反例を幾つ挙げようと、定量的に述べなければ意味がありません。
——————————————————————————————
告
6/8
なぜその熱意を使い、もっと早くにレポートを作成しないのか理 解に苦しみますが、とりあえず午後 12:00 まで受けつける教官が 過半数であることは理解しました。
よって、6/15 の午後 12:00 まで「科学哲学第二」のレポート提出期限を延長します。
——————————————————————————————
告
6/10
「6/15 午後 12:00 まで」ではなく「6/16 に浅川がレターボック スを開けるまで」ではないか、との意見がありましたが、これら は全く違います。必ず 6/15 中に提出するように。
——————————————————————————————
告
6/12
私のレターボックスに猫の死骸を入れたのは誰ですか。
——————————————————————————————
告
6/13
「私がレターボックスを開けた瞬間に波動関数が収束し、内部状 態が定まるので、レターボックスを開けるまではレポートが提出 されたかどうか分からない」と主張したいことは分かりました。
今回は、提出場所を１号館３０２の浅川研究室前のレポート提出 用ボックスにします。
この箱は、6/15 午後 12:00 にシュレッダー へと自動的に切り換わるので、シュレーディンガーの猫の問題は発生しません。
——————————————————————————————
告
6/16
いいかげんにしなさい。午後 12:00 は「グリニッジ標準時」では なく「日本標準時」です。
普段は日本時間で生活しているくせに、レポート提出時だけグリ ニッジ時間を求めるなど言語道断です。
——————————————————————————————
告
6/18
信じ難いことですが、「科学哲学第二」を受講する学生の過半数 がグリニッジ標準時で生活していることが分かりました。
夜型にも程があるとは思いますが、とりあえずレポートの提出は6/30 の午後 12:00 GMT まで待ちます。
——————————————————————————————
告
6/22
時間の連続性についての疑義は受けつけません。どうやらベルグソン の時間論を曲解している者がいるようですが、主観的時間がどうあれ、 7/1 の後に 6/30 が来ることはありません。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
「それで、確かに君は 6/30 中にレポートを提出したというんだね？」
「ええ、ギリギリでした」
「だが、君のレポートは私の手元には無い。君は時間を間違えたのではないかな？」
「いいえ、日に 0.1 秒も狂わない、正確な電波時計を使っていますから。
先生のレポートボックスこそ、時刻を間違えたんじゃないですか？」
「冗談だろう。GPS 補正で ±5 ミリ秒の精度で合わせてある」
「それで、24:00 GMT ちょうどにシュレッダーに切り換わるわけですね？」
「そうだ」
「うーーん。あ、そうだ。多分うるう秒の差ですね」
「うるう秒？」
これは太陽の公転周期から計算する平均太陽時と違い、原子時計によって
計られることになっています。この協定世界時と実際の天文時刻との
差を縮めるため、12/31 や 6/30 などの午後 24:00:00 に、閏年の2月29日
と同様の 1 秒を挿入することがあるんです。いやあ、このうるう秒の
間に僕はレポートを提出して、先生のシュレッダーが動作したんですね。
Windowsでどん。
w32tm /monitor /computers:ntp.jst.mfeed.ad.jp,time.cloudflare.com,ntp.nict.jp,time.google.com,ntp.ring.gr.jp,time.windows.com,time.nist.gov /ipprotocol:4 /nowarn
※調査したPCはntp.jst.mfeed.ad.jpを参照しています。
ICMP: 11ms 遅延
NTP: +0.0014266s ローカル コンピューターの時刻からのオフセット
階層: 2
NICTをソースとするStratum 2のパブリックNTP。
ICMP: 11ms 遅延
NTP: -0.0073322s ローカル コンピューターの時刻からのオフセット
階層: 3
CDNのCloudflareが提供しているNTP。
遅延が少ないのは、東京と大阪にそれぞれサーバがあるかららしい。
ICMP: 10ms 遅延
NTP: +0.0011621s ローカル コンピューターの時刻からのオフセット
階層: 1
日本標準時をソースとするStratum 1のパブリックNTP。
ただし、一時間辺り20回までにしときと注意書きがFAQにある。
ICMP: 38ms 遅延
NTP: -0.0013263s ローカル コンピューターの時刻からのオフセット
階層: 1
Googleが公開しているNTP。ソースは原子時計とのこと。Stratum 1。
ICMP: エラー IP_REQ_TIMED_OUT - 次の時間内に応答がない 1000ms
NTP: エラー ERROR_TIMEOUT - 1000 ミリ秒内にサーバーからの応答がない
福岡大学のNTPを救うために立ち上がった人々によって立ち上げられたNTP。
生きてる？
ICMP: エラー IP_REQ_TIMED_OUT - 次の時間内に応答がない 1000ms
NTP: +0.0003482s ローカル コンピューターの時刻からのオフセット
階層: 3
エラーが出るけど、値は悪くない？
ICMP: エラー IP_REQ_TIMED_OUT - 次の時間内に応答がない 1000ms
NTP: +0.0037770s ローカル コンピューターの時刻からのオフセット
階層: 1
UTC(NIST)をソースとするStratum 1のNTP。
アメリカは遠いよね。うん。
IE11でファイルアップロード機能がいつの間にか動かなくなる事案が発生。
リーダーが履歴を丹念に追いながらこつこつ調べていったところ、フロントエンド側に入ったinputタグの修正が問題だと気づいた。
...なにこれと行き詰まりを見せた中で、無事だった別の画面の同様の処理で
```
<input type="hidden" name="dummy" value="dummy">
```
これはなんだ？と調べると下記のウェブサイトにヒット。
直し方も書いてあった。先ほどの呪文だ。name属性があるinputタグが最後にあればいいのだ。
ありがてぇありがてぇ。
https://stealthinu.hatenadiary.jp/entry/20141106/p1
https://qiita.com/marsa746079/items/a3c69465d605a0078a6b
みんな最初の先人は正直どうしたら気づくの？もしも回答がなかったらどうしてたんだろう。
話は変わるが、アンドロイドのインストール周りで、画面が無限に増えるバグを解決するために死ぬほど苦しんだことがあって
Activity→Intent→Flg値→6進数の値でググるで下記のエントリにあたって命と髪の毛を救われたことがあった。
ありがてぇありがてぇ。
http://d.hatena.ne.jp/kk_Ataka/20130804/1375624170
今日Javaの日本標準時が18:59ずれる問題にあたったブログを拝見したが、
あの時はこんな挙動になるけどなんで？？という人のブログを最初に見つけて
自分もこの事象に遭遇した!!まず、安心したわ。そして解決方法もこっちにありましたよ。ありがとう。
そのブログの人、コメントに反応してくれて二人してわーいと円満に終わることができた。
サマータイムはタイムゾーンの一種と考えることもできるので（該当時期だけタイムゾーンがずれると解釈できる）、複数タイムゾーンにすでに対応しているシステムだと導入は楽だ。
アメリカの場合はタイムゾーンが西部、中部、東部と3つあるので国内向けのシステムでもほとんどがタイムゾーンを意識して作られているし、そもそもタイムゾーンが導入されてから長い。
ところが、日本はどうだろうか？
日本は結構東西に長いのだが、タイムゾーンは一つしかない。日本標準時 JST だ。 UTC より9時間すすんでいるので (UTC+9)と表記される。
複数タイムゾーンに対応したプログラムを作る場合は、内部では UTC に変換して処理や保存を行い、表示と入力部分だけ現地時間に対応するのが一般的だ。
サマータイムになろうが、別タイムゾーンに飛行機で移動中であろうがUTCは常に進み続ける。（正確にはうるう秒があるので1秒間足踏みしたりするのだが）
ローカルタイムはサマータイムになった日とか場所を移動した日には前後に飛んでしまうので時刻順にデータを並べ替えたりするのには使えないのだ。
ちなみにアメリカ軍の戦闘機F-22が日付変更線を超えて沖縄に初めて来たときソフトウェアがバグって修理のためにアメリカに帰って行ったことがあった。笑いごとではない。
さて、日本中にある既存のシステムはどうだろうか？君の作ったシステム、関わったシステムはどうだろう？
MySQLのシステムタイムゾーンをJSTにしていたりしないか？
「JSTで保存して、JSTで出力すればタイムゾーンの変換なんかしなくていいじゃん？だって日本人しか使わないんだぜ？言語のバリアがあるからね（はぁと」
なんてシステムはざらだ。下手すら時刻を文字列型としてJST前提で保存してたりして。
他のシステムと相互通信するソフトウェアはどうだろうか？相手のタイムゾーンがJSTであると仮定していないか？アメリカ西海岸から接続があった時も大丈夫か？
てか、そもそもロジックと表示部分がちゃんと分離されているか？モデルとビューの分離。教科書でならっただろ？
おいおい、ビューで計算したものをモデル側で未チェックで保存したりしてないよな？
テストは書いてあるか？タイムゾーンが変わって時間が飛んだり戻ったりしたデータが送られてきてもこけないようになっているか？
そもそもテストは書いたことあるのか？てかソースはそもそもあるのか？
あー・・頭痛くなってきた。やめよう。
「大臣、無理です！」
昨日、菅官房長官が夏時間検討を否定していて一安心していたのですが、まだ前向きなのではないかと思われる報道がありましたので、もう一回しつこくポストします。
https://www.fnn.jp/posts/00398120CX
夏時間を推進しようとしている議員がネットで情報収集する人種ではないことは、SNS上での皮肉や批判にもかかわらず、こうして事態が進行していることからあきらかです。FAXとかはがきじゃないとだめなのかもしれませんが、幸いWeb上にフォームがあるので、自民党と首相官邸に今すぐ自分の意見を伝えましょう。
https://www.kantei.go.jp/jp/forms/goiken_ssl.html
なぜ、限定的な問題を解決するために社会全体の構造を変更しようとするのでしょうか。私はこのような全体主義的な問題解決姿勢には大反対です。仮に開催を２時間前倒すことで猛暑にオリンピックを実施することに伴う様々な問題が解決するとしても、変更が必要なのはオリンピックのタイムテーブルであり、社会全体の時刻ではありません。
ざっくり言うと、私見では2000年問題と同じぐらいヤバく、準備期間が少ないという意味で破滅的にヤバいです（＝回避不能な2000年問題）。
・世界中で夏時間と冬時間に2時間の差がある国はありません（間違っていたらご指摘ください）。ベストプラクティスが存在しません。
・何を大げさな、単に時計を進めたり戻したりすればいいだけじゃないか、と思うかもしれませんが、現代のコンピューターは世界中の様々なサービスと通信しています。そのため、時間を扱う際には内部的には一旦世界標準時で処理されるのが一般的で、内部時計を二時間進めたり戻したりすると様々な問題が起こります。ロシア/マガダン時間はすでに東京よりも二時間進んでいるので、現実的にはユーザーがスマホやPCの時刻自動設定を解除し、手動でマガダン時間に変更するしかないと思います。
・海外からオリンピックを観に来る旅行者にも「スマホの自動タイムゾーン設定を解除してロシア/マガダン時間に設定してください、マガダンのスペルはM, a, g, a, d...」などと航空会社が案内する感じになるでしょう。日本に来るのになぜかロシア時間。
・一方で、20世紀から稼働している古いシステムや、単純なシステムの中には、そもそも単一のタイムゾーン以外で動作することを考慮していないプログラムもあり、このようなシステムについては、内部時計をずらして対応するしかありません。このようなシステムから見ると、突然タイムスリップした状況に見えます。進む方はまだいいのですが、戻る方の処理は大変複雑です（たとえば、切替日の深夜営業の飲食店では、すでにタイムカードで23:30で打刻した人のあとに、22:30の打刻が出現するような状況になる）。この影響範囲についてはまったく予想がつきません。いい加減に対応すると、時計を進めていないサービスと現在時刻で同意できないために、通信ができないような事態が起こります。
夏時間の概念自体は新しいものではないので、ちゃんと日本夏時間が標準化され、各種OSが対応することが前提であれば、工数をかけて設計・実装を行えば、最新のOS上で新しく開発されるシステムは理屈上は問題なく対応することができます。
しかし、日本だけでなく世界中ですでに稼働している、時刻を表示する無数のプログラムについては、時刻表示に必要な処理や時刻設定に必要な選択肢を書き足す必要があります（日本政府が公式にロシア/マガダン時間を採用すると宣言しない限りは）。十分な準備期間を取らずに、変更が必要な箇所をすべて洗い出し、問題なく修正するのは大変むずかしいことです。また、上述のように、古いシステムではそもそも変更が不可能なこともあります。
万が一いいかげんな実装や適当な設計が行われるシステムが混じっていると、そのシステムと通信する際に２時間時間がずれて処理が行われるようなことが起こります。具体的には様々な表示時刻や予約時刻が２時間ずれたり、通信不通になるなどの問題が起こり得ます。
この結果、
・日本夏時間に正式対応していないので、ユーザーが時刻をロシアマガダン時間に手動設定することで当面正常動作するシステム（古いスマホやPCなど）
・日本夏時間に対応しないために、内部時計を進めたり戻したりして対応するシステム
・日本夏時間に対応せずに日本標準時間のまま動作し、ユーザーが時刻を頭の中で変換しなければいけないシステム
が混在することになり、社会的な混乱は必至です。
人間も機械も「それ、どっちの13時？」みたいに迷い、間違えるという毎日がやってきます。文房具屋のレシートには日本標準時が、コンビニのレシートには日本夏時間が印字されているような感じになるでしょう。ツイッターやフェイスブックなどのもともと複数のタイムゾーンに対応しているシステムや、JRや航空会社など大きい会社はたぶんちゃんと対応してくれますが、美容院の予約システムや小規模なネット予約システムは対応できずに日本標準時のまま稼働し続け、勘違いが起こります。
社会的に大きなメリットがあるのであれば、この大混乱のリスクを取ってでも前進するべきだと思いますが、本件については導入のメリットがあまりに限定的であり、得られるメリットに比べてリスクが大きすぎると思います。
本エントリーは増田文学賞2018前期の投票に関する総合案内用のエントリーです。投票は以下にリンクを張った各部門の投票用エントリーのブコメにて行ってください。また、文学賞全体に関する質問・意見は本エントリーに、各部門に関する質問・意見は部門別投票エントリーにはてブか増田で行ってください。
2018年8月4日：結果を発表しました。発表が遅れ、すみませんでした。
はてな匿名ダイアリー(以下、増田）の匿名性と日記というフォーマットによって生まれた「名乗るほどではない、あるいは名乗ることはできないが誰かに話したい感情や体験、発想をウェブ上で共有し、称え合う文化」を守り、増田のますますの発展に寄与する
(注：以上期間はすべて日本標準時とする)
本文学賞の運営者は、各部門ごとに投票を集計し、投票されたエントリーのうち投票数上位5件を「ノミネート」、最多票を得たエントリーを「受賞エントリー」として投票所上で発表する。
コメント賞を除く全部門の投票を総計し、最も多くの票を得た記事を大賞とする。大賞の発表は別記事にて行う。
集計時はコメント文をプレーンテキストとして扱うので、リンクされなくても大丈夫です。
元号対応で、過去の帳票についてシステムテストを繰り返していたところ、明治初年のテストデータをパスしないバグが見つかった。
Javaのlocaldateが1968/1/1の深夜0時の場合、なぜか1967/12/31の23時41分くらいとなぜか19分ちょい絶妙にずれるため
mmSSを切り捨てる系の日付処理で1967/12/31で検索していることが原因だとすぐにわかったが、
最終的にきしださんのウェブサイトにて日本標準時が1880年を境に江戸城から現在の明石に変更していることを知った。
http://d.hatena.ne.jp/nowokay/20150109
有志が常にtimezoneの変更をJREに行っていることをついでに知る。
http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html
直近だと北朝鮮がつい先日の5月に標準時を変更したらしい。韓国=日本と同じ時間だそうだ。
2015年からたった3年間だけ使われたKorea Timezoneが韓国との融和をうたうパフォーマンスのために一蹴。
北朝鮮にシステム会社がどれだけあるかは知らないけど、中の人たちお疲れ様です。
有名どころで言えば、つい30年前までシンガポールが日本標準時のまま放置していたりしたそうだけど
