タイムゾーンの問題
タイムゾーン終盤号までを目標にして、 終盤号で盛り上がっちゃったら、ちょっと回を2回3回と分け…
そうですね、繰り返しよってちょっと呪いが出るかもしれないです。
エンジニアの呪詛が出るから。
誰かが体調崩すとか。
そうそう、体調崩すかもしれない。ちょっと呪われるから。
TimeTreeTechTalkです。
よろしくお願いします。
よろしくお願いします。
今日はちょっといつもと趣向を変えてですね、 僕が司会進行をするんですが、
夏といえばやっぱり怪談、怪談話、怖い話ですよね。
今日はですね、持ち込み企画珍しい、 エンジニアからの持ち込み企画でですね、
iOSのXeonからカレンダー開発の怖い話あるよということで、
もう怖い話みじろ押しでちょっと進めていきたいと思ってます。
まあ、開発怖い話ってどこの開発の現場にもあると思うんですけど、
カレンダー開発にもいろいろありまして、
そういうところを、
そうだな、これは社内のメンバーが意外と本当に 怖さを感じるんじゃないかなって話になりそうなんですけど、
やっていきますか。
やっていきましょう。
驚々しくみんなで話していきますね。
という、じゃあSEに流してもらっていいですか。
後で探しておこう。
なんかね、いくつか大きなトピックをもらったんですけど、
なので何回かの放送に分かれそうなんですが、
まずは第1弾。
第1弾の怖い話Xeon、何ですか。
タイムゾーンと特にサマータイムの話をしたいと思うんですけど、
タイムゾーンとサマータイム。
そもそもなんでこれやろうと思ったかというと、
カレンダーってすごい生活に溶け込んでいるから、
それをアプリで実装するって時に、
そんなに難しいんじゃないんじゃないかって思うかもしれないんですけど、
思ってる、今も私は。
全然わからない難しさが。
でも実際に開発してみるとすごい複雑な部分があって、
知らないと思わぬ痛い目を見るよっていう、
そういうエンジニアが聞くとすごく怖くなるっていう話を、
今回まとめようかなと思って。
じゃあちょっとこれ聞いてる、
暑さを感じてるエンジニアはこれ聞いて、
背筋をヒヤッとさせて欲しいですね。
で、1個目がタイムゾーンとサマータイム。
時差ってあるじゃないですか。
地球って平面だったらいいなって思うんですけど、
僕は平面だと思ってますよ。
平面だと信じてる方もいらっしゃるようなんですけど、
それも怖いよ。
一般的にはそうじゃないということになってるので、
やっぱ時間が違うんですよね、場所によって。
僕全職Yahooだったんですけど、
その時は日本だけで提供するサービスだったんで、
あんまり考えなくても良かったんですけど、
世界に提供するカレンダーサービスとしては、
当然考えないといけない問題になります。
タイムツリーの機能的な話を、
普通に予定登録する時に時刻を指定すると思うんですけど、
実はその時、端末のタイムゾーン情報も
一緒に予定のデータの中に保存してるんですね。
その端末を旅行とかして別のタイムゾーンに行くと、
端末のタイムゾーンが変わるんで、
その時にカレンダーを開くと、
自動的にそのタイムゾーンでの時刻に変わるっていう。
なるほど。
iPhoneとかってことですね。
そうです。
お持ちのAndroidが国をまたぐと勝手に変えてくれるんですね。
そうです。
その設定を引き継いでタイムツリーのタイムゾーンも変わる。
実はそのアプリの設定の中にタイムゾーン表示オン・オフっていう設定があって、
オンにしとくと別のタイムゾーンの予定に現地時間みたいな感じで、
その予定にひも付いてるタイムゾーンでの時刻も一緒に出るように。
あ、合わせて出るという。
そうですね。
それオフにしてるとどうなる?
多分今と一緒。
基本デフォルトオフのはずなので、標準の表示。
そうですね。その端末が今いるタイムゾーンでの時間で表示される形。
日本でAM10時に設定した予定がロンドンに行くと。
AM1時になってる。
1時になってる。
そういうのすぐ計算で。
ロンドンの時差とかすぐ分かっちゃう。
なるほど。そういう設定になって。
タイムゾーン設定オンにしておくと、
現地時刻と元々東京で設定した予定の時刻両方が定期される。
そういう仕組みになってます。
でも今聞いただけだと、
マイナス9時間とかマイナス15時間とかプラス何時間とか、
なんか簡単な設定に思うんですけど。
そう思うじゃないですか。
まあまあ色々あるんですけど、
まずそのよくある不具合で、
時刻が9時間ずれてるなっていう不具合が
よくあるんですよね。
で、それさっきスコットがスッとロンドン時間に行ってたと思うんですけど。
ちょっとすごかったですよね。
僕たちはもう日本が世界標準時から9時間ずれてるっていうことが頭に入ってるんですよ。
ロンドン時間からはちょうど9時間ずれてるのがあって、
なんかこうお問い合わせとかで風合いで、
時差の問題
なんか9時間ずれるんですけどみたいなのを聞くと、
見るたまにピンとくるんですよ。
これはタイムゾーンの問題だっていう。
実際その9時間ずれるっていうイシューも何個か探すと出てくるんですけど、
日本は世界標準にUTCって言うんですけど、
そこからプラス9時間になっているという感じで、
そこのタイムゾーンの扱いを間違うとずれちゃうっていう問題がよくある。
このずれてるっていうお問い合わせはどういうことなんだ?
タイムゾーンの設定が間違っている?
違うタイムゾーンを設定させちゃってる?
そうですね。
日本時間で扱うべきところをUTCで扱っちゃったりとか、
その逆とかっていうことがアプリの中のコードの不具合で起きちゃっている。
なるほど。
怖いっちゃ怖いですけどね。
この仕組み概念を分かっていないと、そもそも何でずれているのかよく分かるし。
あと一見日本でデバッグしてると普通に動いてるように見えるんで、
その辺、もちろんちゃんとテストしなきゃいけないんですけど、
急いで漏れちゃうとかっていうことはたまにあったりしますし、
日本に住んでると特に時差とかあんまり考えないから。
アメリカとかだとね、週によって時差あるじゃないですか。
だからそういう時差があるもんだと思ってサービス開発とかされてると思うんですけど、
日本って時差ないから国の中で。
あと今思い出したんですけど、よくある問題として、
日本でうまく動くんだけどアメリカでうまく動かないみたいなことがあって、
それは世界標準時からプラスなのかマイナスなのかの違いによって、
ちゃんと動く動かないが分かれたりするんですよ。
時刻を無視して日付だけで扱いたいみたいな時に、
プラスだったら別にそれが端折られて、
同じ日付として扱われるんだけど、
マイナスにずれてるところだと前日に戻っちゃうみたいなことが起きる。
そういう不具合も結構よくあります。
今東京、日本でデバッグしてると気づかない不具合もあるみたいな話があったんですけど、
それは何でだ?タイムゾーンの設定とか。
そうですね、普段僕らが開発してる時に日本のタイムゾーンでテストしてるから。
それは何か工夫はあるんですか?
テスト環境のタイムゾーンを変えるとかそういう話?
そうかな、デバイスのタイムゾーン設定を変えたりして、
とかっていうので再現する。
だんだん怖くなってきましたね。
ユニットテストであえてニューヨーク時間でテストコードを書くとかいうことをしたりします。
それはぶっちゃけどうなんですか?
エンジニアからするとハイパーめんどくさいぜっていう。
そりゃそうなんですけど、やらなきゃいけないことからやってるし。
だんだんそういう風になってくると、僕みたいに地球は平面だって言って、
端っこ行くと落ちちゃうって思う。
だんだん共感が増えてきた、僕も。
もうちょっとだんだん怖くなってきた。
ちなみにサーバーでいうと、これはやっぱクライアントの問題。
見せる時によく変換するんで、サーバーでは全て全部、
世界標準時に変換し直して全部取り扱ってます。
これじゃあ一歩でもミスると、全ユーザーの予定がめちゃくちゃになっちゃう可能性もある?
入力によってタイムゾーンとか変えたりすると、
入力するデータ変えたりすると、
パッと見てどのデータなのか全然わかんないみたいなのは発生しがちなんですよね。
だからそういう意味で言うと、サーバーにあるデータ全部揃える。
これを東京で揃えると、日本人にはわかりやすいんだけど、
グローバル展開するって考えると、世界標準時に合わせた方がいいので、
サーバーに入っている時間は全部マイナス9時間。
なるほど。
日本から登録するとマイナス9時間。
アメリカとかから登録するとプラス何時間かなっていう感じで取り扱ってます。
そういう便利な数字がコンピューターの世界にあって、
ユニックスタイムスタンプって言うんですけど。
データベースに入っている時刻とかがUTCで入っているので、
ここで15時ってなっていると、これは日本時間の0時間。
そうそう、15時はだいたい0時にすぐわかる。
なるほど。
この辺はサービスの初期からこういう風な設定になっているので、
そこはすごくいい設計だったんじゃないかな。
サーバーに関して言うと、これが日本のデータとかになってたりすると、
世界展開するときにプラス何時間すればいいのかパッとわからないんですよね。
初めてカレンダーを開発するエンジニアは、やっぱりここつまずくポイントなんですか?
時間系のサービスをやるときはだいたいそうかもしれない。
カレンダーに限らず。
怖いな、怖いな。
国内にしか展開しないって考えてたら、
日本の標準時に設定するっていうのが一番便利なんですよね。
パッと見て時間わかるから。
その辺はサービスの規模とか、将来の展望とかにすごくよるのかなって思うんですけど、
やっぱり地球はまったいらで全部標準時だったほうがいい。
だからか、何人かいますよね。
狂信的な地球平面論者うちにも。
そうですね、完全に。
もう完全に狂信者。
あとなんか、事前に用意したカンペに次の話題が、
僕の常識を覆す。
もう一歩怖い話に入っていきたいと思うんですけど、
1日が24時間じゃないって。
なんだって?
知ってます?
なんだって?
よくプログラムの中で、
1日後の時刻を計算するみたいなことが必要になったりするんですけど、
現在時刻の1日後の日付を時間を取るっていう。
プログラムの中で時刻を扱うときに、
基準となる時点からの秒数で表すっていうのが一般的にあるんですけど、
その秒数に24時間分の秒数を足せば、
1日後の時刻が出ると思うじゃないですか。
理論上。
サマータイムの問題
これやりがちなんですけど、
これやっちゃダメなんですよ。
例えば、ニューヨークで2023年11月4日の昼の12時。
これの24時間後は、
2023年11月5日の午前11時になります。
なんでずれちゃうかっていうと、
アメリカにはサマータイムがあるので、
11月5日の深夜2時に時計が1時間戻るんですよ。
1時間飛ぶんですね。
怖いなそれ。
1時間消えちゃう。
なのでここで時間がずれちゃうっていう風につながってしまう。
なるほど。
当然逆に時計を進めるっていう瞬間もあるんで、
サマータイムをそもそも実施するのかしらないのかとか、
するとして何月何日の何時にずらすのっていうのは、
地域によって違うんですよ。
やばいな。
なのでこれ正しくやるためには、
ちゃんとタイムゾーンの情報を知ってなきゃいけなくて、
世の中にはタイムゾーンデータベースっていう便利なものがあるんですけれども、
やっぱり同じような苦悩を経てきたエンジニアがちゃんと作ってるんですね。
基本的に多分あらゆるシステムがこれを参照して、
タイムゾーンの計算をしてると思うんですけど、
このデータベースにはそのタイムゾーンは標準時から何時間ずれてるのかとか、
いつサマータイムになっていつ終わるのかみたいな情報が全部入ってるんですね。
タイムゾーンデータベースとサマータイム問題
例えばiOSとかだったら、
標準のSDKの中にこのタイムゾーンデータベースを使って正しく日付を計算できる、
その方法がすでに組み込まれているので、
それを正しく使って計算するっていうのが正しいやり方になってます。
なるほど、このデータベース万が一破壊されたら終わるじゃないですか。
これはでも結構な機関が管理してて、
IANAっていうのか、インターネットに関する機関が管理しているはずって
Wikipediaに書いてあります。
堅牢なデータベースのはずなんですね。
そうですね、グループで管理されてるっていう。
オープンソースだったはずですね。
じゃあもう人類のエイチーなんだ、これは。
そう。
ちょっと戻って、1日後の時刻を計算するっていうのがちょっとよくわかんなくて、
何でそんなことが必要なのかとか。
例えば何かユーザーに訴求する時に何かの操作をした1日後に通知を出したいとか。
なるほど。
サーバーとかだと何時から何時までと予定みたいな検索をする時とかも
タイムゾーン指定してっていうのをやってたりしますね。
デフォルトは全部UTCなんですけど。
そうか、じゃあこれ1日後ってだけじゃなくて、
いろんなパターンもあるってことですね。
それでその日のその時刻にそのタイムゾーンで引っかかるかどうかとかっていうのが
タイムゾーンによって変わってくるので。
なるほどね、それで1時間ずれるって結構なずれですね。
そう、使ってるユーザーさんからすると何でみたいになっちゃうっていう。
2時でしたのに入ってこないみたいな問題とかが発生しがちになったりしますね。
なんか一時期、日本でもサマータイムを導入するかどうかみたいなニュースが出た時があった気がする。
そんなことになったら僕デモしますね。
オリンピックの時ですよね。
そうですそうですそうです。
その時なんかエンジニアがすごいザワザワしてました。
ザワザワしてました。
デモする。
長期化っていうか。
なんかそれぞれのエンジニアのスラッグが結構ザワザワしてた記憶が。
すごい熱いからって話でしたよね確かね。
そんなことになったらもうデモしますよ。
やめてくれみたいな。
そう、やめてくれ頼む。
それがちょうど次の話題なんですけど。
これ政治によって時間が変わるっていうことなんですよ。
優遇式問題ですねこれ。
そうなんですよ。
政治によってね変わりますね。
で、これ最近あったお問い合わせなんですけど。
メキシコのチワワ州っていうところにお住まいのユーザーさんから
時間がずれちゃってますっていうのが来てですね。
これ2022年の10月にメキシコのチワワ州ではサマータイムが廃止されたらしいんですよ。
そうなんですね。
ちょっと住んでないからわかんない。
でもお問い合わせいただいて助かりました。
そうですね。
つまり政治によってその時間が何時になるのかっていうのが結構変わることがあるっていうのが怖くないですか。
怖いですね。
これからもいろいろ変わっていく可能性が十分にあるという。
そうですね。
実は日本もかつてサマータイムをやってたことがあるんですよ。
知らなかったです。
戦後間もなくとかでしたっけ確か。
戦後間もなく3年間ぐらいやったことがあったんですけど
なんか混乱が大きかったのか早々にやめたらしくて。
そういう歴史的な事実もタイムゾーンデータベースにちゃんと入ってるんで。
入ってるんで。
当時の時間をちゃんと出そうとするとおそらくそれがちゃんと反映されてるはずです。
でもそれは過去の分ってことですよね。
そうですね。
何年から何年まで日本のタイムゾーンはこんな感じでとか
このタイムゾーン何年何月に廃止されたとかそういうデータが入ってるんですよね。
なので今回のユーザーさんのお問い合わせが来たときは
そのタイムゾーンデータベースに反映される前の状態でお使いだったからずれちゃっていたと。
なるほど。
これはiOSの場合はそのデータベースはOS側に入ってるので
OSのアップデートしていただくとちゃんと反映されるっていう形になる。
Androidはアプリ側に組み込まれてるのでアプリのアップデートしていただくと反映されるっていう。
そこはちょっと別に言ったら一番。
これってでもじゃあ常にページによって変わるってことは
常に世界情勢ウォッチしてなきゃいけないってことですね。
そうですね。
そんな頻繁に起こるのはあれではないと思います。
すごい複雑なんで全て全部考慮はできないっていうのは難しい。
時間によっても変わるんで。
先月まで動いてたみたいなことだったり
やっぱりそのタイムゾーンが変わるとか
制度が変わることによってみたいなこともあって
世界中のそういうニュース全然覚えてないから
ユーザーさんからありがたいことにお問い合わせいただくことで対応できるようになっておりますね。
でも最近結構その
シャマータイムって実はあんまメリットないんじゃないかっていう研究が
研究結果が出だしてるらしくて
なんかやめようみたいな動きはありますね。
欧州でも廃止するみたいな流れだっていう
ニュースがちょっと前に話題になってたんですけど
なので
歓迎すべきニュースですね。
エンジニア的にはみんなすぐやめろって思ってるんで。
これはでも大変なのは
そんな頻度が多くないとはいえ
やっぱり信頼性とかにつながりますからね
サービスの大事なところで
いろんなところで使っていただいてから発生する問題ではある
ありがたい問題ではあるんですけど
難しい問題ですね。
じゃあカレンダー開発の怖い話第1弾としては
そこそこ怖かったですね。
大玉で
大玉で怖かった
今後の怖い話予告も
シオンに最後してもらえますか。
はい。
政治による時間の変動
まだ続くんですよね。
一応予定してるのだと
終盤号っていうのがまず
終盤号
あと繰り返し予定
このワードはよく聞くな。
このワードはたぶんうちのエンジニアみんな怖いやつ
あとは
これも怖いんですよ
旧歴と録用ですね。
旧歴っていうのは
日本にもあるんですか。
いわゆる本とか昔それで決まってた
あと新聞の日とか
日本だとあんまりね
そんなに意識をしないと思うんですけど
東アジアかな主に
中国とか韓国
台湾あたりとかは
その辺でお休みの時期が決まったり
日常的に旧歴の日付を
使うらしいですね。
違う文化圏だと
韓国とか
正月とかも結構ずれてますし
録用っていうのは
いわゆる対案とか
これは日本だけのものだと思います。
これそんなに怖いんだ
あれ6つをそのまま段々に
割り振っていけばいいんじゃないか
バカなふりして今喋ってますけど
でも旧歴とほぼ一緒
旧歴を確かベースに最初に決まる
旧歴の日付が決まると録用が決まる
でも旧歴の計算が結構大変
もう一個ありますね
割引ですね
昭和平成令は
俺大っ嫌いそれ
超嫌い
今令和何年か分かります?
全く分からない
なるほどね
割引も関係あるんだ
なんで関係あるんですか
iPhoneで割引出せるの知らないですか
設定で割引出せるんですよ
そうするとTime Treeも
割引で出ます
知らなかった
OSの設定ですか
多分これ
Time Treeのエンジニアでも
もしかしたら知らない
マジで知らなかった
でもOSでは設定
でもあれですね
iOSはOSの設定から
いろいろ表示変えたりとか
すごい親切ですね
もうそれでほぼ終わりなんですけど
できるんだっていう
それ知るだけで怖いじゃないですか
そんな時これアプリちゃんと動くの
みたいな
いっぱいあるな
引き続き
また出ていただいて
この怖い話続けていただけると
冬には代わりに
心温まるやつやりましょう
全部話し終わったら
僕らの心すさむかもしれない
ハートウォーミングのやつ冬にやりましょう
じゃあ次回は
終盤号とか
繰り返し予定盛り上がりそうだけど
この辺りもちょっと
詩音に話していただいて
今度ロウソクとか
焚いておきますね
ちょっとあの蝶々とか
ちょっと暗くして
柳の葉っぱ
ありがとうございました
まずはサマータイム
タイムゾーン問題というのを
話していきました
次回もよろしくお願いします
ありがとうございました
