サマータイム

サマータイムの議論がかしましい。情報システムの改修費用が数兆円に届くとか、届かないとか・・・

最近(ってか、もう十年以上)、WEB系のシステムに関わっていて思うことがある。
基本的に、WEBへのアクセスは世界中から可能なので、ファイルの”created_at”(生成日時)フィールドはGST(グリニッジ標準時)になっていて、そこにロケール(地域情報;日時の表現形式や、使用言語、タイムゾーン)を被せた時に、ローカルな日時に換算される、という設計が一般的だと思う。というよりも、英語圏などからのアクセスを想定していたら、当然日時はGSTになっていると思える。「考える必要がない」という理由で、JST(日本標準時)だけでシステムを設計する、(そうすることで、開発コストを下げたい)というのは、自分だったら発想として却下していると思う。大した手間じゃない。View(表示)部分でGSTからJSTに変換すればいいだけ、だから、その部分に若干の手間がかかるけれども、今時のWEB環境ではGSTからローカルタイムへの表示切り替えは、関数一つ使えばいいだけになってるような気がする。

で、そのGSTからJSTへの表示切り替え部分で、他の国ではすでに採用されている夏時間対応の切り替えの仕組みが使えて、時間の切り替え自体は結構簡単じゃないかな、なんて思ったりするんだが・・・もしかして、そうじゃないんだろうか?
表示部分には、それが「夏時間」であることを明示する必要もあるのか、ないのか、わからんけど。

銀行系なんか、国際的なトランザクションも扱っているだろうから、おそらくはGSTが基準になっていると思う。(関わったことがないから、知らないけれど。)航空機などのシステムは、GSTで設計しなければタイムスタンプが滅茶苦茶になる。(離陸後30分経って、着陸したら30分前に戻っていた、とか・・・ヴァニモからジャヤプラへのフライトが、確かこんな感じだった。陸路でも2時間程度の国境越えの路線。)
え?違うの、という疑問符???が頭の中にいっぱい。世の中、わからないことだらけ。

なんだか、そんなに心配する必要ないんじゃないかなぁ、なんていう気がする。いや、世間一般の情報システムを僕が知らなすぎるだけ、かも知れないけれど。もしGSTが基準になっていないなら、この機会に設計変更すべきじゃなかろうか。

人間の側としては、きっと数日の時差ボケがあるような感じかなぁ。ただ、思う。ブラックな企業では、残業時間が絶対に延びる。「もう、夜8時だ。でも外はこんなに明るい。まだあと3時間はいける」みたいな・・・悲鳴をあげるマイノリティが絶対にいると思うな。

個人的には、個別の就業時間とか、営業時間をズラした方が、社会的には楽なのかなぁとも思うけれども、情報システムとしては基幹となる時間表示を動かすよりも、個別の(取引先)の営業時間とかに「夏対応営業時間」フィールドを追加したりする方が、圧倒的に改修の手間とかコストはかかるんじゃないか、なんてことを思った。

でもね、もう僕が大規模システムに関わるようなことは、たぶんないと思うから、他人事かな。

オリンピックが議論のきっかけ?いや、昔は「体育祭」って言ったら「秋」が定番だった。真夏に運動会をやる学校なんて、どこにもなかった。(と思う。知らないだけかもしれない。)国によって「開催時期」を変えられるように、オリンピックそのもののルールを見直した方が、よほどコスト低減に役立つような気がする。
何よりも、日本の秋は、夏よりも訪れたくなる景色の場所が多い、ような気がするけど、もう遅いわな、こんな提案。

うちの会社の就業時間は、ウルトラ・スーパー・フレックスタイムだし。