こんにちは、日本の会社の仕事をしたり、アメリカの会社の仕事をしたり、フランスに住んでたりするもので、日付管理めんどくさい問題という日本の人はほとんど体験しないどうでもいい問題に毎度直面しているひろゆきです。
2020年11月16日を、日本では、2020/11/16と書きますね。年/月/日ですね。
ファイル名にするときは、「20201116.log」とかになります。
1976/10/17は、「19761017.log」みたいになります。。
んで、これを数字の小さい順に並べると、日付の古い順になるのですね。
19761217.log
20201116.log
日本のエンジニアは、これを当たり前だと思ってるし便利に利用してると思います。
さて、フランスの場合は、2020年11月16日を16/11/2020と書きます。日/月/年なのです。
2020年11月16日をファイル名にすると「16112020.log」
1976年12月17日は、17/12/1976、なので「17121976.log」になります。
これを数字の小さい順に並べると2020年のファイルが先に来ちゃうんですよね。。
16112020.log
17121976.log
んで、アメリカは、2020年11月16日を11/16/2020と書きます。月/日/年なのです。
2020年11月16日をファイル名にすると「11162020.log」
1976年12月17日は、16/10/1976、なので「12171976.log」になります。
こちらも数字の小さい順に並べると2020年のファイルが先に来ちゃうんですよね。。11162020.log
12171976.log
んで、フランス人と英語でやりとりをするときに、10/08/2020って書かれると、アメリカ式に10月8日の意味で書いてるのか、フランス式で8月10日で書いてるのかわからないんですよね。。。すげーめんどくさいっす。
この時点で、日本の日付管理は便利だなというのがわかってもらえたと思うのですが、サマータイムというまた厄介な問題がありました。アメリカはまだあります。
夏になると、1時間早くなるという仕組みなんですが、冬になると1時間戻します。
つまり、10月25日の冬時間が終わる日は、深夜1時59分の1分後は、深夜2時00分ではなく、深夜1時00分に戻るのです。
10月25日の時間ごとの記録には、10月25日深夜1時59分（一回目）と10月25日深夜1時59分（2回目）が存在するのですね。
なので、10月25日深夜1時59分（一回目）の10分後は、10月25日深夜1時09分（2回目）になり、10月25日深夜1時59分より10月25日深夜1時09分のほうが後の時間という、何言ってるのかわからないような状態になるわけです。
同じ日付で同じ時間が2回あるとかマジで狂ってると思うので、日本にサマータイムを導入するのは本気で辞めたほうがいいと思います。
ということで、欧州はサマータイムが無くなりました。
アメリカには、さらにタイムゾーンというものがありまして、国がデカいので、地域によって時間が違うんですよね。
太平洋時間の11月16日23時10分は、中部時間では11月17日01時10分で、東部時間では11月17日03時10分なのです。
時間を記録するときに、どのタイムズゾーンの時間なのか？という地名を付けないと正しい時間がわからなくなるのですね。
サマータイム終了日には、同じ時間が2回来て、さらに地名をつけないと、正しい時間がわからないというすげーめんどくさいのがアメリカ仕様です。
ということで、日本の日付管理の優秀さを心のどこかにとどめておいていただけると幸いです。。。
以上、プログラマーの人にしか共感して貰えない話題でした。
―― 面白い未来、探求メディア 『ガジェット通信(GetNews)』
