Splatoonstat.ink

フェスのチーム名(二つ名)の長さ

Splatoon 2 v4.0 からフェスにチーム名(二つ名)がつきました。
この名前は基本的に同じ属性(ブキやギア、性別、髪型)をそろえるとそれが並ぶので、理論値は簡単に出せるのですが、なんとなく stat.ink で観測しているチーム名の一覧を取得してみました。

観測している中で最も長いのは「Tropa inkling con cuernos de diablito, botas enojonas y armas dispares」で 70 文字でした。スペイン語かな。

一番短いのは『「イカ」or「タコ」』と『「ズ」or「会」』の組み合わせの 3 文字です。

日本語はこういうとき、短くなりがち。(1文字の幅は食うので、見た目は長くなるけど) 続きを読む

Splatoonstat.ink

stat.ink: 🐟Salmon Run!

stat.inkではサーモンランへの対応を行いました(v2.19 β から)。
現時点ではベータ版扱いですが、ある程度は普通に使えるはずです。
なお、ご利用には対応アプリケーションによる投稿が必要です。
現時点では、splatnet2statink が対応しています。

You can post Salmon Run results to stat.ink now.
It’s a beta version now and there are some restrictions.
A corresponding application is necessary to use it.
At this time, you can use splatnet2statink to post Salmon Run results.

Enjoy & be fresh!

illustration: いらすとや

PC

サマータイムと「PCの時計を進める/戻す」

最近、サマータイムを導入するべきかどうかの議論が盛んですが、どうも、一般的なコンピュータ(Windows や Linux)の文脈で「時計を合わせる」という考え方があるようです。
端的に答えだけ言うと、一般的なコンピュータにおいて 時計を進めたり戻したりすることはありません し、するものでもありません。

なお、きわめて単純なマイコン(例えば電子レンジやエアコン、炊飯器の時間など)はこの限りではありません。

コンピュータの日時管理

現代の一般的な PC において、ある時点を起点として、サマータイムの実施の有無にかかわらず、一定の間隔で数え続けるのが普通です。
といっても、普通の人には意味がわからないと思います。
現在、一般的に使われているOSでは、(日本時間の)1970年1月1日 午前9時ちょうどからの経過時間を秒単位で保持し、加算しています。
その時間からずっと止まらないストップウォッチだと思ってもらえば良いでしょう。
(閏秒は扱いがめんどくさいのでここでは完全に無視します)

 0秒
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━→ ずっと未来までつづく
1970/1/1 9:00          ↑現在

じゃあ、今が何秒なのかというと、このくらいです→「ここに表示
青い画面で表示されていて、「ここに表示」のままになっている場合は、ここをタップ(あるいはクリック)してください。

この数字は、「ユニックス時間 (UNIX時間)」などと呼ばれていて、世界で共通の値です。

「世界で共通」というのはどういう意味でしょうか。
「今、この瞬間」、日本では「ある時刻」ですが、例えばアメリカでは「別のある時刻」です。

「ある時刻」といってもわかりづらいので、具体的にしましょう。

  • 日本(標準時): 2018年8月15日 12:00
  • 欧州・中央(夏時間): 2018年8月15日 5:00
  • 米国・ニューヨーク(夏時間): 2018年8月14日 23:00
  • 米国・ロサンゼルス(夏時間): 2018年8月14日 20:00
  • 協定世界時 : 2018年8月15日 3:00
  • ユニックス時間 : 1534302000

これらは、同じ瞬間です。
※細かいことを言うと、いろいろありますが、そういうことにしておいてください。実用的にはそれで充分です。

※「協定世界時」は耳慣れない言葉ですが、「グリニッジ標準時と大体同じ」です。歴史的な経緯から、英国のグリニッジ天文台(の近く)を通る子午線をつくり、それを0°として、その地方時を基準としています。
 余談ですが、英国は夏時間を導入しているので、英国の時間と協定世界時は違います。(日本との時差は9時間ですが、夏期には8時間になります)

コンピュータの中の処理で考えると、「現在のユニックス時間」+「タイムゾーン情報」(後述)を使って、「あなたの生活している時間」を表示します。

さて、誰かが何かをした――たとえば、今あなたがツイートした、あるいは何か商品を購入した――時間というのは、今あなたが生活している時間にかかわらず同じ瞬間のはずです。
現在、中央欧州夏時間と日本時間の差は(上述の通り)7時間ですが、今ツイートしたものが欧州で7時間後にやっと表示されたりはしません。当たり前ですが。
ただし、「閲覧者のタイムゾーン」が違うので、「見た目の表示時刻」は異なります。
私たちが「12:00」に起こした出来事が、欧州の人には「5:00」に発生したように表示されます。これは見た目は違いますが、同じ瞬間です。

コンピュータでの時刻の管理はこういった形が基本になっています。

例えば、「ファイルの作成日時」などはそうなっています。
試しにやってみるといいのですが、

  1. ファイルを作成する
  2. プロパティから作成・更新日時を確認する
  3. 設定やコントロールパネルから「タイムゾーン」を別のところ(例えば欧州のお好きな国や米国など)に変更する
  4. もう一度同じファイルのプロパティを確認する

という手順を踏むと、別の日時が表示されると思います。それは、時差を考慮すると、同じタイミングを指しています。
このことから、内部では「(表示上の)時刻」を見ているわけではなく、「ある瞬間」を保存していて、表示時に頑張って「設定されているタイムゾーン = 生活している時間」に変換していることがわかります。
この「表示時にやっている」というのが大変重要です。

例えば、今私が適当なファイルをUSBメモリなりSDカードなりSDXCカード(64GB以上)なりCD-Rなりに格納して、アメリカ在住のEliの所に送付すると、私の手元で確認した保存時間と、Eliの手元で確認した時の保存時間は異なります。 FAT32はローカルタイムでの保存らしいのでこの部分の記述を訂正します。SDXCもUTCによる記録はオプションのようなので怪しいかもしれません。
しかしそれは時差を考慮すれば「同じ瞬間」を示します。

サマータイムに合わせて「時計を変える」ということ

今、サマータイムが突然開始されて、2時間進んだとしましょう。
あなたは、慌てて設定から「時刻の変更」を選んで時計を2時間すすめました。

たぶん、「PCの時計を進めればいい」と言っている人はこういう感覚だと思います。

さて、先ほどの長文を踏まえて、この対応は正しいでしょうか。

答えは、もちろん正しくありません

今、たぶん世の中の時刻はこうなっているはずです。

  • 日本(二重夏時間): 2018年8月15日 14:00
  • 欧州・中央(夏時間): 2018年8月15日 5:00
  • 米国・ニューヨーク(夏時間): 2018年8月14日 23:00
  • 米国・ロサンゼルス(夏時間): 2018年8月14日 20:00
  • 協定世界時 : 2018年8月15日 3:00

これらは先の例と変わらず「同じ瞬間」を指しているはずです。
そして、「時計を2時間進めた」日本の人の時計はこうなってしまっています。

  • 日本(標準時): 2018年8月15日 14:00
  • 欧州・中央(夏時間): 2018年8月15日 7:00
  • 米国・ニューヨーク(夏時間): 2018年8月15日 1:00
  • 米国・ロサンゼルス(夏時間): 2018年8月14日 22:00
  • 協定世界時 : 2018年8月15日 5:00

これは世界の時刻との整合性が取れなくなってしまっています。あいつら、未来に生きてんなというやつです。あなたのPCだけ世界から2時間進んでしまっています。

正しい対応の方法

普通のOS(雑な言い方)では、「この地域では、協定世界時に対して何時間ずれた時刻で生活をしている」という情報を持っています。
これを一般に「タイムゾーン情報」とか「時間帯情報」とかいいます。「tzdata」とかもいいます。まあ、何でもいいです。
雑に言うと、「協定世界時との時差」の情報を全世界分持っています。

また、すでに夏時間が導入されている国や地域などでは、「いつからいつまで夏時間」という情報も同時に持っています。
過去に実施されていた「日本の夏時間」にも対応したデータがあります。
夏時間以外にも、「標準時の変更」の情報もこれに含まれています。
例えば、北朝鮮の標準時が +9:00 から +8:30 になって +9:00 に戻った情報も記録されており、(仮に北朝鮮の時刻で表示しようとすれば)正しく反映されます。

コンピュータは、このデータベースと、(たぶん記憶にないと思いますが)利用者がPCのセットアップ時に設定した「日本で利用」(設定上は「東京、大阪、札幌」や「Asia/Tokyo」)という情報をもとに、適切な日時に変換して表示しています。

このデータベースの更新は、一般に OS のアップデートに含まれて配布されます。
(一部の環境では個別に更新することもあります)

つまり、正しい対応としては、マイクロソフト等が夏時間の実施情報をOSの一部に組み込み、それを配布することになります。

サポート中のOSに関しては、この時間帯情報が配布されますので、普通にアップデートしていれば問題ありません。
夏時間の実施時刻になると勝手に反映されます。
XPやVista、古いAndroidなどサポートされていないOSに関しては、この情報は配布されないでしょう。

さて、サポートされていないOSをどうしても使いたい場合はどうしたらいいでしょうか。使わないというのはとりあえずなしで。
時計を2時間進めますか?

どうしても、そのような環境を使用したい場合は、協定世界時に対して11時間進んだ時間帯を使用しているところに居ることにする のが妥当でしょう。
あるいは、人間が頑張って読み替える

こうしないと、身近なところでは、USBメモリなどでやり取りしたときに2時間ずれて表示されるなどの問題が発生します。
その他、記録時間等が信頼できなくなるので、警察対応や裁判などで信頼性が問われる可能性もあります。

正しい対応のまとめです。

  • ちゃんとサポート中のOSを使う
  • ちゃんとOSを更新する
  • ちゃんと更新されたOSでは、時計を変更する必要は全くない。むしろ変更してはダメ。
  • どうしてもそのような環境を使えない場合は、UTC+11 のタイムゾーンにいることにして設定を変更する(時計を変更するのではなく、居る場所を変更する)。

Windows や Mac、iOS (iPhone/iPad) についてはサポート中なら大丈夫と言える(Appleはサポート期限明示してないのはおいておく)けど、Android どうするんだろう…。
ただでさえ Android のアップデートろくに降ってこないのにサポート対応できるのかな…。

NTP や GPS

NTPやGPSの時間でも勘違いしている人がいます。
※NTP: ネットワーク越しに「正しい」時間を受け取るための仕組み。
※GPS: ご存知、現在位置を測定するための仕組み。電波に「正確な日時」を含むため時刻同期に使用可能。

NTPやGPSの時刻情報は(数え始める基準日が違いますが)、「ある基準日時からの経過秒」を示します。
「ユニックス時間」の親戚だと思ってもらえればよく、(精度問題(=どこまで細かく表現できるか。1/1000秒なのか、1/1000000秒なのかという意味)を無視すれば)、相互に変換できます。

アメリカのNTPサーバに同期しても、あなたのPCの時計はアメリカ時間になったりしません。
たぶん、今のWindowsを普通にインストールすると、自動的に「time.windows.com」というNTPサーバと同期するように設定されていると思います。
このtime.windows.comはたぶんアメリカにあると思いますが、世界中のどこにあったとしても、期待通りに動作します。
NTPサーバが「基準時刻」を送信する→PCが「基準時刻」を「ユニックス時間(等の内部時間)に変換する」→表示するときに、タイムゾーン情報を参照して人間が読める日時に変換する、という流れです。

このことからわかる通り、「表示のための日時」とは関係ありません。
コンピュータは受け取った時刻情報と、タイムゾーンの情報をもとに人間に対して提示します。

GPSは、そもそも「宇宙から電波を一方的に送り付けているだけ」ということから明らかですが、世界で共通のデータであり、タイムゾーン情報を含んでいるはずがありません。
(ロシアの「グロナス」というGPSに似た衛星システムは、常にモスクワ時間を送信していますが、これも「3時間の時差を含んでいる」ことを除けば同じです)
日本に電波が届いたということは、1時間ずれている中国や台湾にも届いている可能性は高いですからね。
何より、国内の主要領土だけで4つのタイムゾーンをもっている米国の仕組みですから、そんなアホなことにはなっていません。
(GPSの信号は、自分の居場所と正確な時間を送り続けるだけです。この信号を複数受信して方程式を解くと、緯度・経度・高度・時間がわかります)

GPSはタイムゾーン情報を含んでいないということは、身近なところでは何が起きるでしょうか。

おそらく、カーナビはGPSから時間をもらっていると思いますが、これを正しい日本時間で表示するためには、タイムゾーンデータベースの更新が必要です。
果たしてカーナビのタイムゾーンDBのアップデートは来るでしょうか。(まあ、来ないですよね、その時点での最新機種以外は)
そもそも、日本製カーナビ、途中でタイムゾーンが変化する可能性とか考慮してるのかな…。

まあカーナビくらいなら時間がずれていても、大したことにはなりません。
カーナビには詳しくないのですが、時間帯によって規制(車両通行禁止など)や料金変更(高速道路とか)を考慮するような機種が存在するのなら、そのあたりには影響するかもしれません。
まあ、普通はこの程度では「人は死なない」ので、大した問題ではないです。

じゃあサマータイムに特に問題は発生しないの?

本当に表示だけしかしないプログラムであれば(←ここ大変重要)、その可能性は高いでしょう。
昔の政府の調査で、「交通信号の対応にこれだけかかりますよ」みたいなのがあるみたいですが、あれは簡単な部類だと考えられます。
(切替タイミングでおかしくしなければ、タイムゾーン情報を持てればあとは「表示」だけなので。ものすごく変なプログラムを組んでいたら、夏時間から戻る時に2時間以上赤になりっぱなしとか面白いことは起こせるかもしれません。)

例えば、勤怠管理、簡単に言うとタイムカードの処理を考えます。大体サマータイムの実施は深夜なので、深夜勤務ですね。
2019-06-02 1:59:59.999 の次(0.001 秒後)を 2019-06-02 4:00:00.000 にする 2 時間のサマータイムを実施するとしましょう。
日本で作成されている一般的なプログラムでは、「2019-06-01 22:00:00 出勤、2019-06-02 06:00:00 退勤」などと記録します。
さて、今までであればこれを 6時(=30時) から 22 時を引いて、8 時間勤務 と計算できるわけです。
しかし、この勤務時間計算は間違っています。本当の勤務時間は 6 時間です。これによって、経営者は 2 時間分余計に給料を払わなければならなくなる可能性があります。

この場合でサマータイムの開始時はまだマシです。戻すことも考えてみましょう。
2019-10-06 3:59:59.999 の次を 2019-10-06 02:00:00.000 とする標準時への変更を考えます。(おかしな表記に見えますが、実際にこんな感じになります)
同様に、「2019-10-05 22:00:00 出勤、2019-10-06 06:00:00 退勤」と記録します。
これも8時間ではありません。10時間勤務が正しい計算となります。超過勤務ですね。うっかり 2 時間分もらい損ねないようにしないと。

業界によっては、「退勤から次の出勤までの間隔」を定めていて、それを下回る勤務はできないことになっているところもあるらしいです。
(たとえば、退勤から出勤まで8時間以上必要など。夏時間突入を考えずに計算すると、6時間でスケジュールを組んでしまいかねません)
そのようなところでは、「ある日は夜の長さが2時間短く、別のある日は2時間長い」ということを考慮するようにしなければなりません。

医療や農業で、「4 時間ごとに処理 A を行う必要がある」ようなものも想定できます。
「処理 A」は何らかの薬剤の投与だったり、水まきだったりするでしょう。医療関係者でも農業関係者でもないので知りませんけど。

今、午前0時ちょうどに処理を行ったとします。次の処理は午前4時ちょうどです。
さて、この状態(「午前4時に処理をする」と予約している状態)で、午前2時からサマータイムが開始されたらどうなるでしょうか。
時計は午前2時になろうとした瞬間に、午前4時になります
そのシステムは、午前4時になったので「処理 A」を行います。

さて、この「処理 A」の間隔はどうなったでしょうか。
「午前0時」の次に「午前4時」の処理を行っていますが、間は2時間です。
水やり程度ならまあ大した影響はないと思いますが、薬剤の投与だったりすると過剰投与になって大惨事ですかね。

サマータイム終了時にも、「午前4時になった(なろうとした)瞬間に午前2時に戻る」ということが起きるので、同じようなことが発生しかねません。
まあ医療関係の器具がそんな作りになっているとは思えませんが、サマータイム導入前に、そんな作りになっていないことを確認する必要があります。

サマータイムを導入すると、一日の長さが24時間固定ではなくなるわけですから、現在のように、単純な数字の足し算引き算では対応できなくなるわけです。
このあたり、日本のプログラム全てがちゃんと対応できているとは思えません。
※2時間のサマータイムを導入すると、「22時間の日が1日、26時間の日が1日、24時間の日が363日か364日」になります。

これに対する正しい対応方法は、『「協定世界時(UTC)」などで記録し、入出力するときにローカル時間(日本時間)との変換を行う』ような感じになります。
日本で稼働しているシステムで、現在このように処理しているシステムの数は……たぶん半分もないんじゃないですかね。
(コンピュータが普及する前にサマータイムを開始している欧州や米国は、最初からそのようにプログラムを書いているはずです)

単に「協定世界時で処理をして、きちんと計算すればいい」とも言い切れません。
日本人は一日の長さが変動するなんて夢にも思っていませんから、当たり前のように「24時間後に」とか「1日後に」とか仕様を決めます。2日や7日でも同じです。
果たしてその仕様とされた「24時間」というのは本当に24時間でいいのでしょうか。「1日」のつもりで書かれたものではないでしょうか。
サマータイムを導入すると、1日と24時間は等しくなくなります
例えば「24時間乾燥させる」のような要件の場合は、本当に24時間で処理するのが妥当なのでしょう。
一方で、「24時間以内に連絡」のような場合は、単に「1日後」のつもりで書かれている可能性があるので、1日後の同時刻とするのが正しいかもしれません。
これは、システムや文脈によって個別に判断しなければなりません。これはとても大変なことです。

仮に「1日後の同時刻」を求められている場合、 協定世界時では1日は24時間ですから、「1日後の同時刻」を計算するためには、一回日本のローカル時間に変換したり、夏時間のルールを参照したりしないといけません。
ですから、単に「協定世界時で処理してるから表示だけの問題だもーん」ともなりません。

また、よくある「日時を選ぶ」入力も問題になります。
上のサマータイム実施例で「2019-10-05 03:00:00」と入力された場合、さて、これは1回目の3時でしょうか、2回目の3時でしょうか。
この問題に関しては、多分、欧州や米国の人は「このあたりにルーズになる」ことで対応しているのだと思います。適当。

ほかにも、「システム連携で日本時間を送りあう。大幅にずれていればエラー」とするようなシステムがあって、どちらかが「夏時間には対応しない」などとすれば問題になります。

時間の計算や連携をしなくても、現在のコンピュータシステムでは「夜間にデータをまとめて処理する」ようなことが多々あります。これを「夜間バッチ」などといいます。
この「夜間バッチ」の終了が結構業務開始ギリギリになっている場合があります。
サマータイム開始時には一日の長さが22時間の日がある(夜が2時間短い)ことになりますから、この処理が間に合わない可能性があります。
これによって、銀行の業務などが停止し、ATMが使えないなどの障害が発生するかもしれません。

この夜間バッチに関しては、「間に合わない」だけではなくて、「いつ起動するか」も問題になります。
「毎日 2:30 にこの処理を実行してね」と書いている場合、(サマータイムの実施開始・終了日を無視すれば)毎日1回、ほぼ24時間ごとに実行されることになります。これは実際によくある処理です。
サマータイム開始日には「その時刻が存在しない」可能性、終了日には「その時刻が2回ある」可能性があります。どちらも大惨事を引き起こしかねません。
そのような場合にいつ、何回起動されるかは実装によって異なります。
「サマータイム対応」には「そのような場合にどうなるか」の確認も必要なわけですね。

元号や消費税率の変更のような「いつか確実に、あるいは、きっと起きるもの」については、あらかじめ仕組みを用意しておくのが合理的です。
特に改元はその性質上、「明日変わるかもしれない」ものですから必須とも言えます。
一方で、夏時間のように「やるかどうかも不明、やるとしてもどうやるのか不明」なものに関しては、準備しておくのが必ずしも合理的とは言えません。

変わることがわかっているものは「ここを変える」と印をつけているか、最初から変えやすいようにしておくのが一般的です。
一方で、「夏時間は存在しない」という前提のもとで長年作られている日本のシステムは、「どこを変更したらいいか」もわからないようになっています。
影響があるかどうかを調査するだけで膨大なコストになるでしょう。
そもそも、大半の日本のプログラマは「夏時間を考慮する」というのが何が必要なのか理解できていないと思われます。そこの勉強からやらないといけないわけです。

まずですね、こんな解説の記事が必要になってる時点で夏時間に対する理解が足りているとは到底言えないわけです。

よく言われていること

二時間のサマータイムは前例がないのでOS等の対応が行われていない

嘘と言っていいです。OS等には「サマータイムは1時間である」と仮定したコードは無いと考えて良いです。
世の中には30分のサマータイムを実施している地域も存在しますし、過去にはイギリスで「二重夏時間」を導入し、2時間ずれていたこともあります。

また、夏時間とは関係のない「標準時」の変更も同様の仕組みで行いますから、たぶん秒単位で扱えるはずです。

ただし、標準電波(電波時計用によく使われる。JJY)のフォーマットが 1 時間しか考慮していない 話のように、「アプリケーションレベル」と言われる単位では、1時間と想定している可能性もあります。

「Asia/Tokyo」は「JST = 日本標準時」を示し、サマータイムとは関係がない

ちょっと何を言っているかよくわからないです。

Asia/Tokyo タイムゾーンは、”東京で使われている・使われていた・使われるであろう” タイムゾーンの情報であり、当然に夏時間の情報も含みます。
Europe/Paris タイムゾーンとか少し試してみればわかりますが、シームレスに切り替わります。

自分のところは夏時間に関することはスルーする(夏時間を適用しない)ので、何もしなくて問題ない

OSを更新した時にタイムゾーンデータベースが勝手に更新されないように措置すれば、そうですね。
その場合の法的整合性とかについては知りませんけど。
また、未来の保守において、その部分が足を引っ張る可能性がありますから充分に注意してください。
(未来のOSを導入すれば、当然その日時には夏時間が適用されるというデータを持っていますよね)

コンピュータの時間は変わらないことになりますが、きっと周りの時間は2時間進むので、それはそれで茨の道になる可能性があります。
安易に判断しないほうが良いですよ。

  • バッチ突き抜け問題
  • ログとかが2時間ずれる

じゃあ「韓国時間(Asia/Seoul)」とかにしておけばいい?

韓国では何度か夏時間の実施の実績がありますから、1988年以前のデータを扱う可能性があるならやめておいた方が無難です。
また、日本の時刻に関する法律から逃れる代わりに、韓国のそれに影響されるようになりますから、韓国で夏時間が施行されないか充分に注意をしてください。
まあ、デメリットしかない今の時代に夏時間を導入とか、まともであればしないと思いますけど。

あ、韓国は「+9:00はE135°子午線通ってないし、日本の支配の残滓でもあるから標準時を+8:30に変えよう」という運動がずっとくすぶってるようですから、それにも注意してください。
これも、今のところはデメリット大きすぎるからダメだ、と、まともな判断がされているようですが。

なお、周りの時間がずれることによるデメリットは上の「何もしない」と同じです。

一部の業務システムでデータを失う可能性があるってどういうこと?

この記事は、「コンピュータの中の時計は好き勝手にいじるものじゃないよ」という内容なので、完全に別の話ではあるのですが、一応。はてブコメントもついてるし。

この辺は実装に強く依存するので一概には言えないのですが、設計によっては(そのままだと)データを一部失う可能性があります。

例えば、24時間受付で、何かを受注するシステムを考えます。(オンラインショッピングとかが当てはまりますね)

その受注システムは、一時間に一回、YYYYMMDDHH.dat というファイル名で受注データを作成して、一日数回、合計24ファイルを別のシステムに引き渡すとします
YYYYMMDD = 年月日、HH=00~23時)
実際のシステムでは、こういう何かをまとめたデータだったり、ログデータだったりします。
まあ「ありそうな処理」です。

さて、夏時間が終了する日の事を考えましょう。
ここでは、上でも例に使った、「2019-10-06 3:59:59.999 の次を 2019-10-06 02:00:00.000 とする」移行とします。
上の仕様だと、0分になった直後にそういう処理をするプログラムを起動すればいいですかね。こんな感じで。
※(夏) は夏時間、(冬) は日本標準時を指します。

  • 2019年10月6日 00:00(夏) 頃 : 2019100523.dat を作成
  • 2019年10月6日 01:00(夏) 頃 : 2019100600.dat を作成
  • 2019年10月6日 02:00(夏) 頃 : 2019100601.dat を作成
  • 2019年10月6日 03:00(夏) 頃 : 2019100602.dat を作成
  • 2019年10月6日 02:00(冬) 頃 : 2019100601.dat を作成(!)(あるいは2019100603.dat を作成)
  • 2019年10月6日 03:00(冬) 頃 : 2019100602.dat を作成(!)
  • 2019年10月6日 04:00(冬) 頃 : 2019100603.dat を作成

さて、お気づきの通り、ファイル名が重複してしまいました。
重複した時は何が起きるでしょうか。これはもちろん実装によりますが、

  • ファイルが存在するのでエラーになる
  • ファイルが存在するので上書きする
  • ファイルに追記する

まあどれかになるでしょう。どれもありそうです。最後のはめんどくさいですからあんまりなさそうな気はします。

エラーになるとそれはそれで惨事ですが、上書きされたらもう大惨事です。
一部のデータを失ってしまいます。

「一部のデータを失う可能性がある」というのはこういうことです。

同様のケースで、1時間なり2時間に一回バックアップを取得している場合で、同様のファイル名をつけていたりすると、同じようなことが起きます。

この問題を修正するには、「この部分だけ常に冬時間で処理する」とか「この部分の仕様を変更する」とかしないといけません。
仕様の変更ができるのか、冬時間で処理しても問題ないのか、そういった確認も行う必要があるわけです。

また、このようなファイル名をつけている場合にさらに問題になるところがあります。

(必ずしも)ファイル名が時系列に並ばないのです。
このようなファイル名をつけている場合、「ファイル名で並び替えると時系列になる」と想定している可能性はそれなりにあります。
みなさんもきっと、日付をファイル名につけておいて、並び替えて時系列にしたことの一度や二度、あると思います。私はあります。たくさん。
日本時間にサマータイムが存在しないなら、そのような想定もそれなりに合理的であるわけで、「このような想定を行っていないことを保証せよ」と急に迫られても大変困るわけです。

Splatoonstat.ink

stat.ink: August update

I’ve added 4 weapons and a stage to stat.ink.

Key-string Japanese
(literally/rōmaji)
English
quadhopper_white クアッドホッパーホワイト
Quad hopper white
kuaddo hoppā howaito
Light Tetra Dualies
hydra_custom ハイドラントカスタム
Hydrant custom
haidoranto kasutamu
Custom Hydra Splatling
furo オーバーフロッシャー
Over flosher
ōbā furosshā
Bloblobber
nautilus47 ノーチラス47
Nautilus 47
nōchirasu 47
Nautilus 47
anchovy アンチョビットゲームズ
Ancho-bit games
anchobitto gēmuzu
Ancho-V Games
Splatoonstat.ink

stat.ink: July update

I’ve added 4 weapons and a stage to stat.ink.

Key-string Japanese
(literally/rōmaji)
English
bamboo14mk2 14式竹筒銃・乙
Type 14 bamboo-tube-gun mark 2
hitoyon-shiki takezutsujū otsu
Bamboozler 14 Mk II
explosher エクスプロッシャー
Explosher
ekusupurosshā
Explosher
kugelschreiber クーゲルシュライバー
German: Kugelschreiber
kūgerushuraibā
Ballpoint Splatling
campingshelter_sorella キャンピングシェルターソレーラ
Camping shelter sorella
kyampingu sherutā sorēra
Tenta Sorella Brella
otoro ホテルニューオートロ
Hotel New Ōtoro (tuna)
hoteru nyū ōtoro
New Albacore Hotel
Splatoonstat.ink

stat.ink: Add for June

I’ve added 4 weapons and a stage to stat.ink.

Key-string Japanese
(literally/rōmaji)
English
dualsweeper_custom デュアルスイーパーカスタム
Dual Sweeper Custom
duaru suīpā kasutamu
Custom Dualie Squelchers
rapid_elite_deco Rブラスターエリートデコ
R (Rapid) Blaster Elite Deco
āru (rapiddo) burasutā erīto deko
Rapid Blaster Pro Deco
spygadget_sorella スパイガジェットソレーラ
Spy Gadget Sorella
supai gajetto sorēra
Undercover Sorella Brella
carbon_deco カーボンローラーデコ
Carbon Roller Deco
kābon rōrā deko
Carbon Roller Deco
sumeshi スメーシーワールド
Sumeshi(Vinegared Rice) World
sumēshī wārudo
Wahoo World
Splatoonstat.ink

フェスパワー差の集計

先日開催されたフェスについて、Splatoon公式から次のような発表がありました。

ということで、手元に stat.ink のデータベースがあるので、それを使って調べてみました。

次の表がフェスパワーの差とその割合を調べたものです。
stat.ink は投稿者に偏りがあるので必ずしも全体を反映したものではありませんが、ミスがなければ、「今回のフェス」と「今までのフェス」には大きな違いは見られないはずです。 続きを読む

Splatoonstat.ink

stat.ink: Ready for Splatoon 2 v3.0.0

stat.ink は Splatoon 2 バージョン 3.0.0 への準備ができました(たぶん)。
Stat.ink now ready for Splatoon 2 version 3.0.0 (maybe).

  • ウデマエ X をサポートしています。 Supported “Rank X.” (For app developers: Please refer the API doc.)
  • X パワーをサポートしています。 Supported “X Power.” (For app developers: Please refer the API doc.)
  • 5月分のブキを追加済みです。 Added weapons that will add in May (end of April).
  • 5月分のステージを追加済みです。 Added a stage, Camp Triggerfish, that will add in May (end of April).
Key-string Japanese
(literally/rōmaji)
English Key-string from
sharp_neo シャープマーカーネオ
Sharp Marker Neo
shāpu mākā neo
Neo Splash-o-matic Ja
bottlegeyser_foil ボトルガイザーフォイル
Bottle Geyser Foil
botoru gaizā foiru
Foil Squeezer Ja
kelvin525_deco ケルビン525デコ
Kelvin 525 Deco
kerub(v)in 525 deko
Glooga Dualies Deco Ja
squiclean_b スクイックリンβ
Squid-clean Beta
sukuikkurin bēta
New Squiffer Ja
mongara モンガラキャンプ場
Triggerfish Campsite
mongara kyampujō
Camp Triggerfish Ja
Splatoonstat.ink

stat.ink: Add Custom Range Blaster

stat.ink にロングブラスターカスタムを追加しました。
APIに指定するためのキー文字列は “longblaster_custom” です。

I’ve added the Custom Range Blaster to stat.ink for Splatoon 2.
The key-string for the API is “longblaster_custom,” from its Japanese name “ロングブラスターカスタム” (Rōmaji: rongu brasutā kasutamu; Literally: Long Blaster Custom).

Splatoonstat.ink

stat.ink: Add Tri-Slosher Nouveau

stat.ink にヒッセン・ヒューを追加しました。
API に指定するためのキーは “hissen_hue” です。

I’ve added the Tri-Slosher Nouveau to stat.ink for Splatoon 2.
The key-string for the API is “hissen_hue,” from its Japanese name “ヒッセン・ヒュー (筆洗・ヒュー; Rōmaji: hissen hyū, literally: Brush-washer Hue).”

何があったというわけではありませんが、このバージョンを何となく v2.0.0 にしました。
本当に何となくなので、特に意味はありません。