  |
はてなキーワード: タイムゾーンとは
ワールドカップで優勝できる国は4年の間に平均して50試合程度をこなしている。
Tier1はシックスネーションズやチャンピオンシップに参加することでこの試合数を経験できる。
Tier1とTier2の最も大きな違いがここにある。優勝できない国の代表はそもそも経験できる試合数が少ないのだ。
そういう意味で日本が今回Tier1のアイルランドとスコットランドを倒して予選突破できたのはやはりサンウルブズの存在が大きい。
日本代表としてではないがサンウルブズとしてスーパーラグビーで経験を重ねることが予選突破には必要だった。
代表のユニフォームを着ていてもサンウルブズのユニフォームを着ていても俺たちは一つのチーム、というのが「One Team」というスローガンの持つサブテキスト的な意味である。
各国の代表監督が欲しがっても決して与えられることのない「チームとして成熟させるための練習時間」を唯一充分に与えられたのがジョセフHCだった。
ジョセフHCの手腕をもってしても、この素晴らしい日本代表を作り上げるには3年間毎日のように一緒に練習するという膨大な時間が必要で、その時間はサンウルブズ構想を推進したジョーンズ前HCの置き土産だ。
しかしサンウルブズは(金がかかるという理由で)日本ラグビー協会のバックアップが得られずスーパーラグビーから姿を消すことになる。
2021年以降の日本代表の強化にはサンウルブズに代わる何かが必要で、それが環太平洋リーグ構想(という名の日本国内のプロリーグ構想)につながる。
環太平洋リーグが魅力的なものになれば個々の選手の力の底上げにつながるだろうが、サンウルブズのような代表クローンチームでもなければ代表の強化にはならない。
日本のトップリーグにはすでに一流のコーチも選手も結構いて、そういう意味では環太平洋リーグ構想はうまくいく見込みが全くないというわけではない。
しかし、仮に2027年のラグビーワールドカップの開催がアメリカになったとしたら。
アメリカはもちろんアメフトの国でラグビーはマイナースポーツだが、立ち上がったばかりのMLR(メジャーリーグラグビー)というプロリーグを持っている。
しかも協会に選手登録している人の数は12万人で日本より少し多いほどである(人口比でいえば日本の方が高いが)。
アメリカのスポーツ産業がラグビーの魅力に気づいたとき、環太平洋リーグがある程度の成功で終わっていたらうかうかしていられない状況になる。
サッカー不毛の地と呼ばれたアメリカでFIFAワールドカップが開かれて25年、MLS(メジャーリーグサッカー)の平均観客動員はJ1を少し上回る2万人程度にまで拡大している。
資本が入り、日本国内12か所で行われるプロリーグと同等以上の報酬をMLRが用意できるようになったとしたら、オーストラリア・ニュージーランド・南アフリカの選手はどちらを生活の拠点に選ぶだろうか。
少し脇道にそれた。
日本代表にとって次のフランスワールドカップまでに必要なこと。
それは何よりも必要最低限の試合数の確保である。できれば真剣勝負の。
シックスネーションズに入れてもらえるなら断る理由はない。(遠すぎタイムゾーン違いすぎでそもそも誘ってもらえない可能性の方が遥かに高いが)
ウェブマスター オフィスアワー 2019 年 10 月 02 日 メモ（※所々抜け漏れあり）
https://www.youtube.com/watch?v=bBurTQBqhS0
11/25 Webmaster Conference Tokyo：今週か来週の早い段階で情報を公開する予定
最新情報への対応や常に変動するランキングに対応させるためのもの
「何かまずいところがないだろうか？」という視点でサイトに着手するのは不要
客観的にいいのか悪いのかを知るために定期的なユーザーテストの実施とか、
お互いにレビューし合う習慣を付けるとか
品質評価ガイドラインとかE-A-Tとかは個人的には見なくても良いと思うが、
Q.RankBrainにおける更新性や更新の有無による効果はあるのか？
A.オフィスアワーでランキング要素の可能性について言及するのは難しい。言えることはコンテンツの内容を改善してくださいということだけ。もし、更新性が影響すると言ってしまうとみんながそっちに走ってしまうので。
Q.被リンクではページランクとドメインランクのどちらを重要視していますか？
A.ショートアンサーとしてはどちらでもありません。
仮にドメインランクが重要ですと言ったら何が起こるでしょうか？オールドドメインの買い占めが発生してしまうでしょう。
例えばコンテンツの質を見るに、Wikipediaに関連リンクを貼られるとかそのくらいの影響力があるのかなどを見てみると良いでしょう。
筆者注：
【図解】グーグルのリンク評価20の原則【2019年版】（前編#1～#10） | Moz - SEOとインバウンドマーケティングの実践情報 | Web担当者Forum
https://webtan.impress.co.jp/e/2019/09/30/34042
初心者必見!SEO対策の基本を5分で完全解説【2019年最新版】
https://emma.tools/magazine/seo-basics/
↑これら記事とか？
A.Googleのアルゴリズムも完璧ではないので、アップデートで再評価される可能性はある。
メインのクエリでユーザーが自身のサービスが頭に浮かぶような存在になれるかどうか。
Q.robots.txtでブロックしていないURLなのに、カバレッジでrobots.txtでブロックされていますというエラーが出る
A.色々確認中ではありますが、私が調べた範疇では問題ありません。Search Consoleのフィードバックも送ってください。その際、スクリーンショットだけではなく、テキストで問題点も添えてください。
Q.サイト内画像をサムネイルとして表示したい。Googleが推奨する方法がありませんか？
A.特にそのやり方については公開はしておりません。Googleが良いと思った画像だけを採用します。
強いて対策を言えば、画像のヘルプを参考に画像の情報をGoogleに伝えるようにしてください。
A.確認しましたが、Search Consoleに表示されています。
タイムラグがあるかもしれませんがDisallowされていませんか？確認してみてください。
Q.HTTPSのSearch Consoleは追加した方が良い？重複コンテンツになりますか？？
A.追加した方が良いです。
重複コンテンツによって、起こるのはどちらかのコンテンツが上位表示される可能性があるということ。
共倒れになるということはありません。
そのクエリで頭に浮かぶくらいの存在になっているかどうかです。
Q.セパレートURLにおいてMFI後のcanonicalURLの設定について
正規化とは同等のページ内容のURLが複数あるからこそ行うもの。
canonicalよりも、リダイレクトでやってみてはどうでしょうか？
Q.検索パフォーマンスのデータの収集開始タイミングはいつから？？
A.基本的には登録前のデータも取れるはずですが、違うケースもあればフィードバックで教えて下さい。
Q.Search Consoleのプロパティへの表示について、所有者として確認されてから６日経ってもプロパティに表示されていません
A.何らかの判断で時間がかかったのだと思います。通常は数日ですが、遅れたのは新規サイトであることが要因である可能性があることです。なにか不具合ありましたらSearch Consoleへフィードバックをぜひお願いします。
A.かなり困っているご様子ですので取り上げましたが、当フォーラムでは対象外の話題ですのでウェブ検索フォーラムへ送信願います。
Q.max-image-preview robots meta の値を確認するには？
A.まだ反映されていないのでもうちょっと待てば反映されます。
Q.Search ConsoleのタイムゾーンについてPTからPSTとPDTに切り替わりますか？
A.切り替わります！！
Q.ドメインを変えずにサイト名だけを変えると検索順位はどう変わる？
A.サイト名ほど大きな要素を変えてしまうのは影響すると思います。
どういうサイト名に変えるのかも重要。ユーザーにとってわかりやすくなるとかであれば、長期的には有効になるかもしれません。
Q.max-image-preview でlargeを設定するとDiscoverに表示されやすいと聞きましたがAMP対応しているだけでDiscoverに表示されやすくなりますか？
A.AMPでもmax-image-previewでlargeでもどっちでも対応可能です。
Q.クロールエラーが特定できない件について、１月のオフィスアワーにてホスティング会社に相談してみては？との回答で、のち、６月に検証中とのことでしたがあれからいかがでしょうか？
A.あまり気にされなくても良いです。ただ、間違ったエラーが表示されないようにするためにエンジニアも調整中ではあります。
こういうエラーに気づかれましたらSearch Consoleのフィードバックをぜひお願いします。
次回は１０月後半か１１月前半の予定です
はあ、女児が普段からディルドやローターで開発するよう義務教育で勉強させれば良いのに。
数え切れないですよ。その子達を救わなきゃ。
そう今日クラブ言ったんですよ、ラテン系の女の子がたくさん来るクラブ。
そこで仲良くなった金髪でクリっとした目の女の子に、結婚にはお金が必要だっていうんです。
でも結婚して賃貸住んで子供も作らなければそんなにお金いらないでしょと言ったら、結婚には持ち家が必須条件なのが当然だしって言われその考えは無かったわ。
周りにいたペルーやコロンビア人もそういうんですよ。別に彼女たち金持ちじゃないですよ。
全くどうなってるんでしょうか。そんなことに金使ってるから南アメリカは貧しいんだ。うそうそ。今後経度単位での土地面積が最も多い地域が勝つからアメリカ大陸はまだまだ有力なんですよ。
ネットワークの発展でね。それぞれの国で生まれる先天的な天才の割合は変わらないと研究出てたよね。そう、みんな同じ能力になったら同じタイムゾーン内でいかにチームワークを発揮できるかが鍵なんです。
だからこそアフリカにみんな投資してる。アフリカはみんなすごくセックス大好きでポッシビリティの塊なのです。
サマータイム関連でマウント取りたいプログラマーがブコメやブログ書いてるけど
もしかしてこんなびっくり低レベルプログラマーが世の中のいろんなプログラミングしてるの？
サマータイムよりそっちの方が怖い。
プログラムで時刻を扱う場合はほぼほぼ１００％ライブラリの機能を使う。
日付なり時刻を表すオブジェクトを作る。
そうしないと単純な引き算とか足し算が面倒だろ？
今から10日後ってどうやって計算する？一ヶ月は必ず30日じゃないんだぞ？
だからライブラリに任せる。そこそこのプログラマーなら面倒なことをいちいち実装しない。
で、そういう実装をすると内部で保存されてる時間情報と表示する情報は別物になる。
たいていは内部ではUTCで保存されていて、そいつを表示の時にJSTにする。
OSなりのロケール情報から何で表示するべきなのかを取って来てそれに合わせて表示させる。
サマータイム対応をする場合はこのロケール情報を変えるのであって、内部の時計は変更しない。
だからほとんど全ての時間的演算は影響を受けないし、コードを変える必要もない。
だから正確に言うとサマータイムが導入されても「時計は変更しない」
表示を変えるだけだ。内部時計と表示の関係をわかってない人が多すぎる。
はてなの（おそらくエアプ）プログラマーがその辺をわからずに記事にしてるのがほんとキモい。
で、そんじゃ影響はないか、っていうとそうじゃない。
さっきの10日後、みたいな演算は影響を受ける。２時間ずれる。
あと、簡単なところだとcronなんかのスケジューラは影響を受ける。
夜中の1時に実行するっていうcronの設定はロケールに応じて意味が変わるので、切り替えの時に1日に２回実行されたりするかもしれない。
ただ、利用者側に見えないところのスケジュール実行なら、ぶっちゃけサマータイム対応させる必要はないと思ってる。
サマータイムなんて所詮は人間が見たときの時間であって、内部の時計の話ではないからだ。
エクセルがタイムゾーンに対応していないとかの話もあるが、スタンドアローンで動いてるなら全く問題ない。
影響は皆無ではないしかなり大きいと思うが、OSの更新とかそんな大それた話ではないはずだ。（もちろん、将来的に変更する必要はある）
じゃぁサマータイム賛成なのか？って言われるとそれは別だ。
おそらくスケジューラの影響だけでも相当大変だし、それに関連したシステムの再検証とかどう考えても時間が間に合わない。
内部のコードがどうなってるかわからないから時間に関係してる・していないに関わらずシステムは全て再検証だろう。
どう考えても無理なのは無理だが、根本的に無理かと言われたらそうでもないはずなんだ。
もしかしてハードコードでJSTって書いてたり、独自の時間管理ライブラリを使ったりしてる人って結構いるのか？
String time = "2018-08-16 13:41:00"
とかやってんの？
スタンドアローンならそれでもいい（勝手に電源落として時計あわせりゃいい）が、そうじゃないシステムでそんなアホなことしてる人って多いの？
以前、短期間だけど、B2B通信のミドルウェアメーカーにいた。B2B通信っていうのは企業間でのデータのやりとりのこと。
あなたが近所のスーパーやドラッグストアで買い物をしているとする。お店は品物を仕入れるため、B2B通信で「冷えピタを20ケース売ってください」というデータを送り、受け取った卸売業者は「受注しましたよ」というデータを返す。卸売業者はさらに、メーカーに対して発注データを送り、メーカーは卸売業者に受注しましたよというデータを返す。
あるいは、あなたがAmazonで買い物をしたとする。Amazonはクレジットカード会社に請求データを送り、クレジットカード会社は成否をAmazonに返す。
あるいは、あなたが使っているA銀行の口座から、別のB銀行の口座に振込をしたとする。当然、銀行間でやり取りが行われる。
こういうデータのやり取りが、毎日恐ろしい件数で行われている。サマータイムが導入されるとしたら、B2B通信にも影響がある。ちょっと考えただけでも、
サマータイム導入が決まった場合、そういった問題が起きないように対応しなければいけないわけだけど、
限られた予算の枠内でサマータイム導入にコストを取られるということは、それ以外の施策は後回しになる。停滞のもとだ。
対応方法が企業によってばらけそうなところも問題だ。B2B通信しているすべての企業が揃って完璧な対応をできれば問題ない。でも、場合によっては、「うちはIT予算に余裕がないので、サマータイムの切り替わりタイミングでサーバの時計を2時間ずらすだけにします」みたいなところも出てくるだろう。そうすると、「時刻は確かに2時間ずらされているけど、タイムゾーンの指定はJSTのまま」みたいなデータが送られてくることになる。メーカーとユーザ企業の力関係にもよるけど、ミドルウェアでは「通信相手ごとにサマータイムの対応方法が違う」という前提で複雑なプログラムを組まないといけなくなるかもしれない。
おそらく、サマータイムの開始・終了時には、夜間にも関わらず関係各社の担当者が待機させられることになるだろう。B2B通信も夜中には頻度が下がるのが確かだけど、ないわけではない。データの種類によっては「毎日1回夜中の3:00に送る」みたいなケースもある。万が一何も起きなければ安心して寝ればいいけど、何か障害が起きた場合、影響が大きくなる早朝までに対応しなければいけないので、ミドルウェアメーカーの運用担当者も開発担当者も召集され、タクシーで集まって全員で対応するハメに、というのも十分ありうる。
海外との取引がある企業もあるから、日本だけの話でもない。「へぇ、日本でもサマータイム導入されるんだ。どれどれ、このJDTっていう1時間ずれるやつかな」なんて中途半端に対応されてトラブルになるケースもあるかもしれない。
……ここまで書いてきて思ったけど、サマータイムの対応で問題なのは、費用負担が一番大きいんじゃないだろうか。
オリンピックは、主催者や、そこから仕事をもらっている広告代理店、建築業者、スポーツ用品メーカーなどが収入を得る。それ自体は別にいいんだけど、そのためにサマータイムが導入されて、オリンピックと関係ない企業や、そこで働く人たちが負担を求められている。娯楽はそもそも、提供する側がサービスして、享受する側がお金を払うという交換をするわけだけど、サマータイム導入で反感を買っているのは、オリンピックから直接利益を受けない企業や人が、「あくまでサマータイム対応にコストがかかるのであって、オリンピックにお金を徴収わけではないから問題ない」という論理でタダ働きさせられることが大きい気がする。いわば、日本全体から金をふんだくって、オリンピック主催者・関係者に集約するかたちになっている、その構図が問題なのではないか。
そこで提案なんだけど、「サマータイムは導入してもいいから、対応にかかる費用を東京オリンピック主催者に請求できる」というかたちに持っていくのがいいのでは。
「いやいや、開始までの時間が残り少ないのが問題だよ」という意見もあると思うけど、費用が請求できるなら、優先度上げてできることが色々増えるよね。単純に人を増やしたり、深夜残業代にあてることだけじゃなくて。
たぶん、開催時刻をずらすんじゃなくてサマータイム導入、という話が出たのも、「IOCとの契約で時間が決まっちゃってるから変えると違約金払わされる」とかそういうことだと想像するので、サマータイム対応にかかる費用を主催者が負担して違約金回避できるなら、問題ないよね。……まさか、対応費用が払えないほど莫大になることがわかっていて、それを全国の企業に押し付けようとしているわけではないよね？ もちろん、「サマータイム対応費用を都や国が補助金とか出して負担する」ではダメですよ。それだと結局、主催者が儲かるために国民全員に負担を押し付けるかたちになっちゃうので。
いやぁ、いい案を思いついた。これなら全員がニッコリ、Win-Winな感じになれそうですね。よかったよかった。
会社でどんな影響がでるのか調べてみたので、メモしておきます。
・チャイム
40年ものの機材。始業と昼休みと終業を告げるチャイムを車内に鳴らす。放っておいても1か月に5分進む微妙な精度。サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
・FAX
時計が入っていて、タイムスタンプが入るよね。あれはあまりいじったことないけど、サマータイム機能とかなさそう。海外展開していたら、ありそうだけど、日本仕様は機能をデチューンしてそう。
UTC時を基準に動いているので、対応は可能。現在の日本ではサマータイムがないので、タイムゾーンを東京・大阪あたりを選ぶとサマータイム機能がオフになるようになっている。正式にサマータイムが決定して、windowsアップデート後にサマータイム機能が利用可能になる。
・携帯電話
いわゆるガラケー（ガラパゴス携帯）は、一応、電波で時計の調整がかかっているので、キャリアが対応すれば、勝手に変わりそうな気がする。スマホもOS自体は対応してそう。アプリは開発者ごとに国際化対応を考えていたかどうかなんだろう。
電波の元が調整したら勝手に変わるのか。テストしたことなないだろうから、実際に発動させたら大変そう。
サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
これが厄介。開始時間にバーコードを読み、さらに終了時間にバーコードを読むようなプログラムの場合、通常時間からサマータイムに変更されるタイミングにかかったときに正しい経過時間が記録されない恐れがある。多分、夜中に行うのであれば、いまのところ影響は回避できそう。24時間操業のところだと困りそう。サーバーは、そのまま放っておくというのも手のような気がした。記録を引きだす必要があるときに変換するとか、解釈するというのが現実解かも。
・予定表プログラム
同じ時間が2回くるタイミングと2時間飛ぶタイミングはどう表現しようか。深夜のことなので、寝ているだろうからスルーしていいのだろうか。切り替えタイミングのときに例外処理をいれたほうが親切かな。現時点では同じ数え方で時間が経過することを前提に描画しているので、サマータイムによる時刻の変更は想定していない。実際にない制度のことを想定してコストをかけても誰もお金を払ってくれないよね。
サマータイムの初日は、夜勤の後の朝の交代の人は2時間早くくるのか。サマータイムの終わりの日は、2時間残業しないと次の交代の人がこないのか。
だったら、サマータイム導入して「ほら7時開始のままで暑さが和らいだでしょ？」ってやったって、欧米タイムゾーン基準ではけっきょく開始時刻がずれちゃうんだから、ダメなんじゃないの？
サマータイムはタイムゾーンの一種と考えることもできるので（該当時期だけタイムゾーンがずれると解釈できる）、複数タイムゾーンにすでに対応しているシステムだと導入は楽だ。
アメリカの場合はタイムゾーンが西部、中部、東部と3つあるので国内向けのシステムでもほとんどがタイムゾーンを意識して作られているし、そもそもタイムゾーンが導入されてから長い。
ところが、日本はどうだろうか？
日本は結構東西に長いのだが、タイムゾーンは一つしかない。日本標準時 JST だ。 UTC より9時間すすんでいるので (UTC+9)と表記される。
複数タイムゾーンに対応したプログラムを作る場合は、内部では UTC に変換して処理や保存を行い、表示と入力部分だけ現地時間に対応するのが一般的だ。
サマータイムになろうが、別タイムゾーンに飛行機で移動中であろうがUTCは常に進み続ける。（正確にはうるう秒があるので1秒間足踏みしたりするのだが）
ローカルタイムはサマータイムになった日とか場所を移動した日には前後に飛んでしまうので時刻順にデータを並べ替えたりするのには使えないのだ。
ちなみにアメリカ軍の戦闘機F-22が日付変更線を超えて沖縄に初めて来たときソフトウェアがバグって修理のためにアメリカに帰って行ったことがあった。笑いごとではない。
さて、日本中にある既存のシステムはどうだろうか？君の作ったシステム、関わったシステムはどうだろう？
MySQLのシステムタイムゾーンをJSTにしていたりしないか？
「JSTで保存して、JSTで出力すればタイムゾーンの変換なんかしなくていいじゃん？だって日本人しか使わないんだぜ？言語のバリアがあるからね（はぁと」
なんてシステムはざらだ。下手すら時刻を文字列型としてJST前提で保存してたりして。
他のシステムと相互通信するソフトウェアはどうだろうか？相手のタイムゾーンがJSTであると仮定していないか？アメリカ西海岸から接続があった時も大丈夫か？
てか、そもそもロジックと表示部分がちゃんと分離されているか？モデルとビューの分離。教科書でならっただろ？
おいおい、ビューで計算したものをモデル側で未チェックで保存したりしてないよな？
テストは書いてあるか？タイムゾーンが変わって時間が飛んだり戻ったりしたデータが送られてきてもこけないようになっているか？
そもそもテストは書いたことあるのか？てかソースはそもそもあるのか？
あー・・頭痛くなってきた。やめよう。
「大臣、無理です！」
システム面で問題とか言ってる人は本当にシステム開発したことあんの？
一番びびったのは
とか言ってる人．
普通にスマホの設定からタイムゾーンを+9から+11に変更したら変更できるんですけど．
そもそもタイムゾーンはネットワークから設定できるので通信会社が変更すれば変わりますけど．
まぁそりゃぁ一部のアプリはタイムゾーンをいきなり変えたら不具合起きるかもしれんけど
はっきり言って今のご時世でタイムゾーンを考えないでアプリに時刻の概念を導入している時点でお察しですよ
「システム系は大変なんだ！」
みたいなこと言ってる人いるけどさ，具体的に何が大変なの？
OSのタイムゾーンを+11にするだけでしょ？そりゃテストとかいるけどさ．
それで不具合が出るようなプログラムって逆にどうやって作るの？
時刻とかライブラリ越しで取得するでしょ？そいつをUNIX時間に変換して計算するなりDBに入れるだけじゃないの？
表示の時もシステムのタイムゾーンで表示するでしょ？ハードコードで+9とかJSTって入れてるってこと？
そんなプログラムはどっかに致命的なバグ抱えてるからこれを機に入れ替えた方がいいよ．マジで．
唯一心配なのはスケジューラ系だけど，逆にそこさえチェックすればどうにでもなるんじゃないの？
たかだかサマータイムっていうかタイムゾーン変更に対応できないような機器が基幹系に入ってるとかぶっちゃけ入れた奴が悪いし
てかそういうのは手動で合わせればよくね？合わせられない機器ってあるの？
って，そもそもIoT系の機器は盛大にズレるのでntpが必須ですけど．使ったこと無いの？
サマータイムっていう制度に問題があるってのは理解できるので導入には全然賛成じゃないんだけど
昨日、菅官房長官が夏時間検討を否定していて一安心していたのですが、まだ前向きなのではないかと思われる報道がありましたので、もう一回しつこくポストします。
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や航空会社など大きい会社はたぶんちゃんと対応してくれますが、美容院の予約システムや小規模なネット予約システムは対応できずに日本標準時のまま稼働し続け、勘違いが起こります。
社会的に大きなメリットがあるのであれば、この大混乱のリスクを取ってでも前進するべきだと思いますが、本件については導入のメリットがあまりに限定的であり、得られるメリットに比べてリスクが大きすぎると思います。
日本とヨーロッパといった超遠距離恋愛の秘訣をこれまでの経験をふまえて。
日本国内での遠距離恋愛では、時差もない、会おうと思えばお金さえ払えば数時間で会える。わけですが、日本とヨーロッパともなると、会おうと思い立ってから実際に会えるまで24時間くらいはかかってしまうし、お金だって少なくとも往復で10万はかかります。安くしようと思うと会うまでに要する時間はもっと増えます。乗り継ぎの乗り継ぎを重ね、遠回りすることになるので。ドバイとか経由すると安いですが、距離が2倍近くなりますよ。
話が逸れました。
まず、なにより大切なのは相手を信頼すること。そんなに難しいことではないです。けど、それが一番難しいのも事実で。
ではどうやって信頼するか。
定期的に連絡をとる。これはやっぱり必要です。連絡の頻度は2人のタイプによります。日本にいても結構会いたいタイプの2人なら、毎日連絡したって構いません。
毎日電話しても構いません。お互いのことを信頼できるのなら、いくらでも連絡すれば良いのです。
落ち着いてきたから連絡の頻度を下げようか？そんなことを考えることもあるでしょう。しかし、無理に頻度を落とす必要はありません。2人が連絡をとりたいのなら連絡すれば良いと思います。ただし、相手の負担にならないことは重要です。
特に、日本とヨーロッパでは時差がかなりあります。サマータイムが終わると時差がさらに1時間大きくなるので、連絡する時間帯を変えた方が良いことも。
お互いに働いているのなら、ヨーロッパが夜で日本が朝というのが連絡しやすいかも。ただし、日付が違うので「今日」とか「明日」という言葉が意味をなしません。
相手のタイムゾーンを考えながら、思いやりをもって話しましょう。また、深夜のテンションと早朝のテンションという落差が発生する可能性があります。この点も相手のことを考えてあげられると理想的です。夜の側は下ネタとか言い出すこともあるので、広い心で受け入れてあげましょう（笑）
お互いに学生だったり、時間の融通が利く職業なのであれば、そこは柔軟に対応するのもありです。お互いの負担にならない時間帯を選びましょう。
こんな感じで、電話はやろうと思えば毎日でもできます。毎日電話をしていても、定期的に行って欲しいことはテレビ電話です。
顔を見るのは恥ずかしい？気持ちはわかりますが、やっぱり顔を見ながら話すのって大事ですよ。電話では見落としている部分もあります。恋人ほど他人と近い関係になることって普通はないので、お互いのことをよく知るためにも、思いやるためにもときどき顔を見て話すのが良いと思います。2人の休みが合うときにはぜひテレビ電話を。
電話はこんな感じで。LINEとかメッセージはどうしようか。それは毎日したほうが良いかなー。おはよう。おやすみ。だけでも良いと思います。もちろん、もっと送りたければどうぞ。「今日は天気がよくて気持ちいいよ」とか、些細なこともシェアするのは良いことです。物理的な距離が離れているので、心の距離を近くするには良さそう。電話は毎日しなくても、ちょっとだけメッセージの交換を毎日しているのは良いと思います。自然消滅防止のためにも大事ではないかと思います。
たまには手紙を書いてみたり、贈り物をするのも良いと思います。男性から女性にこれをやるときっと喜んでくれますよ。特に、手紙は超遠距離でもないと書く機会がないと思います。将来結婚でもしたら良い思い出になると思いますので、オススメです。
どんなにマメに連絡していても、やはり「会う」ことは重要です。常に次のデートの予定を持っておくのはとても重要なことだと思います。
それが数ヶ月先だとしても、2人にとって楽しみなことが待っていると辛くても頑張れます。
仕事で日本に帰る用事があるなら、そのときに少しでも会う、デートする。というのが良いと思います。2人の休みが会えば、ヨーロッパを一緒に旅行するのも良いでしょう。もちろん、中間地点で会うのも良いかもしれませんが、毎回中間地点で会うのは、「会う」という目的を達成するためにはあまり経済的ではありません。もちろん、2人が旅行したい場所が中間地点にあるのならば良いと思います。
経済的に考えるなら、どちらかがもう一方のところへ会いに行く。というのが良さそうです。相手の家に泊まれば宿泊費もかかりませんし。ただし、いつも同じ方が会いに行くというのは経済的な負担の偏りが2人の関係を悪化させてしまうこともあるので、滞在中の食事代はもう一方が出すとか、何か対策を講じましょう。いずれにしても、うまくバランスを取りながら定期的に会う予定を入れておくことは必要です。重要です。定期的に会うことで、信頼も深まります。
まとまりがありませんが、経験に基づく超遠距離恋愛の秘訣でした。これから超遠距離恋愛の予定がある方、うまくいくことを祈っています。
ユーザIDは変更させない仕様にするからいい? 顧客に対しては確かにそれでいいかもしれない。でもfuckとかsuckとかrootとかadminとか、あなたの社名とか、あるいは後日の事情でその文字列の塩梅が悪くなったら、どうする?
GUIDが何を指すかによるけど、これはアリ
初回登録日時でも悪くなさそう。
十分に悪くないけど、日時って精度やタイムゾーンや暦というファクターがあるものだから、少し気持ち悪い。
time_t的なものなら大丈夫? そうだね。でも「初回登録日時」が何を指すか、パスワードを決めさせる前の仮登録なのか本登録なのか、解釈が揺れるリスクが少しありそうなのも気持ち悪い。
これらはどっちかというとコード保守の範疇の話だけどね。でもいつかの未来にタコなスタッフが不十分な理解でコードをいじる可能性を考えると、やっぱり気持ち悪い。
これもアリ。いわゆるsaltだね。というか、これ「も」使うのが普通。
たぶんどこにも書いてないのでメモ。
https://developers.google.com/apps-script/reference/utilities/utilities#formatDate(Date,String,String)]
timeZone のフォーマットについての言及がないが、"GMT" 以外のタイムゾーンを設定するには、たとえば +09:00 (JST) の場合、
Utilities.formatDate(new Date, 'Etc/GMT-9', "yyyy-MM-dd'T'HH:mm:ss'Z'");
