この記事は 一分で読める小ネタのカレンダー | Advent Calendar 2023 - Qiita の１６日目
なぜ深く広くか
- ITエンジニアに求められる資質のひとつに知的探究心があると思ってる（別に異論は認める）
- 無知を既知にすることで今までできなかったことができるようになる
- 神は細部に宿るって言うし、使うかどうかは別として、ささいなことについても縦に深く横に広い知識を持っていることはいつか役に立つ
- アプリの深掘りの時には書かなったけど、仕事や勉強とは別に思考を意図的に広げたり深めたりする訓練はきっといつか役に立つ
例えばなにを
- 表現方法の違うもの、規格の決まっているもの、当たり前にそこにあるものならなんでもいい
- なぜそうなっているのか
- 誰が決めているのか
- どうしてそうしなければならなかったか
- なんでも構わないので疑問に思うこと、それを調べることで知見を広げること、それを日常的に繰り返す訓練をして欲しい
- 深く掘り下げるのは突き詰めていくこと
- 広く広げていくのは関係する別のことに視線を向けること
本文はここまで。以下は時間外ｗ
例えば日付（日時、時刻、datetimeなど）について考えてみる
- この記事が公開されるのは（qiitaの仕様どおりなら）2023年12月16日午前7時すぎのはず
- 関連する日付情報はどのくらいあるか考える
-
2023年12月16日： qiita の画面上の日付情報（ほとんど時刻に関する情報は出ないね） -
2023年12月16日 7時x分： 同じ表現で時刻を出力するとこんな感じのはず -
午前7:xx · 2023年12月16日： X'(旧Twitter) だとこんな感じ -
2023-12-16 07:xx:xx： たぶんDBにはこんな感じで入ってる。作成日時は11/26だけど。更新日時や履歴情報にはもっと異なる日付が入っている。複数の日付データを持っているはずということと一般的なRDBのdatetime型について知れればいい -
2023/12/16 07:xx:xx： 個人的にはスラッシュのほうが見やすいけど海外ではあまり一般的ではないみたい？ -
Fri, 15 Dec 2023 07:00:00 +0900： RFC 2822 形式 -
2023-12-15T07:00:00+09:00： ISO 8601 形式 -
2023-12-15 07:00:00.000000000+09:00： RFC 3339 形式 -
1702591200： 1970-01-01 00:00:00 UTC からの秒数 - この他にも英国式、米国式（月日の表示順序が異なる）や、日本では和暦表示などがある
- 時間の表記については時差の関係で 7:00 以外の国のほうが多い
- バッチを cron で実行しているなら
0 22 30,1-24 11,12 *こんな感じの指定がされるはず（実際にはもうちょい真面目に書いてると思うけど） - 一口に日付（時刻）と言っても、使うところや必要な場所によって表現形式が複数あって、適不適がある（ということを知っておいて欲しい）
-
- 日付表現に関する検討事項がどのくらいあるか考える
- 表現方法（ユーザの目に入るところ、プログラム的なところ、データストア上など）
- データ交換（RSSなど）
- タイムゾーン（JST,UTCなど）
- 海外ではどう表現するか（海外から見たことないので知らないけど。要チェック：サモア）
- 必要な知見と必要のない知見を分離できる能力を身につける
- 日本での表示専用と割り切れば日付に関しても日本を中心に考えれば済む
- 例えば github など世界中で使われているサービスの場合、日付情報はできるだけ正確に扱いたいはず
- サマータイムは日本にない（昔あったが今は廃止）が、海外にはあるので、どう管理するかは大事
- ちなみに日本には時差がない（日本全体で標準時が１つ）けど、東端と西端では２時間分のずれがある（各地の日の出の時間で知れる）
- モバイルアプリなどを海外展開する場合、表現方法やバッチの処理時間に注意する必要がある（かもしれない。アメリカ発のゲームだと日本では変な時間に切り替えがおきる。。。逆も然り）
- 今自分が書いているプログラムで日付表現がどの程度重要なのか、を今一度見直してみる
- アクセスログの日時表現との差とか（CDNやLBやWebサーバなど、機器やその配置でTZが異なるとか）
- 他に日付や時刻について知っているべきことは何か、逆に知らなくても問題ないことは何か
- 暦の問題（ユリウス暦、グレゴリオ暦、日本では1873年。和暦の切り替え日など）
- 日数計算、特に過去日付との差分、時差やサマータイムが絡む場合。1873年以前の日付とは日数がずれる。閏年の計算も含めると軽く死ねる
- 閏年（これは普通に多くの場合に必要）
- 閏秒（割りと気にしたほうがいいはずだけどあっさり放置されがち。ログやデータストアでどう扱われるか）
- ネタとして、思考実験として、日付にまつわる小ネタを考える
- タイムトラベル系の娯楽作品で指定した日時計算が誤っていたら（過去は実績値から計算できても、未来は計算できないじゃん？）
- サマータイム計算された？単純な算術演算だけでは30年前だって算出するの大変（それはそれとしてBtF面白いよね）
- 地軸のずれは計算されたのか（地球の地軸はちょっとずつずれる＝タイムトラベル時の位置情報を狙った位置にするためには？）
- 同じように自転速度の違いは計算されたのか
- 位置情報がずれるにあたって、コリオリ力は働くのか
- そもそもタイムトラベルという発想の中の位置情報は地球上の現在地が基準に扱われるが、天体は自転しつつ公転しているので、空間系移動の際に狙った位置を算出するのはとても大変なのではないか
- みたいな益体もないことを思考すると視野が広がって超楽しい
雑
- 最初は小さいプログラムを書く訓練をしよう、みたいなネタを考えていたんだけど、日付処理を考えた時に、先に表現方法の違いとか、目を向けるべきところとか、そういうのを考える時間を取りたくなった（から書いた）
- ChatGPT とかに聞くと大抵のことは教えてくれるけど、AIに頼る前後に自分で考えてみる癖を作って欲しいなと
- 自力で掘ったり広げたりが難しいと思ったら、守備範囲外の本を読むといいかもしれない
- 天井写真を撮るのがちょっとした趣味なんだけど、そこから建築に興味を持って、建築様式や歴史について、規格、サイズの辞典とか、上下水道の仕組みから道路の構造を経て都市計画に至って、って感じで知見を広げてみたんだけど、システム開発でもやってることは同じだなって
- ものの名前を知るのも楽しくて、建造物の構造の名前とか、分類の名前、規格の名前、とにかく”それ”を知ることって知的探究心そのもので、プログラムを考えるに当たって、知らないことを調べて知っていく行動そのものが癖？みたいになってると楽なのかなって
- 学問としての宗教とか、哲学とか、言語学とか、なんでも、専門家になるわけじゃないし試験に合格しないといけないわけでもないし、全てを暗記したりソラんじれるほど覚えないといけないわけじゃないので、気楽に楽しめばいいと思う
- ご覧のとおり益体もない記事になるｗ
改善依頼
- 日付や時刻に関する小ネタください
- 日付や時刻の取り扱いについてこうやってるぜ、をドキュメント化してるところがあったらご紹介ください
- 小ネタに別の視野があったらぜひｗ