人々の誕生日がタイムゾーンを移動すると変わるのは、開発者が単一の日付を保存するのに日時（タイムスタンプ）を使っているからだよ。適当な基準日（例えば、Excelで使われている1900年1月1日とか、僕のお気に入りの1600年1月1日。1600は400の倍数だから、うるう年の計算がさらに簡単になる）を選んで、そこから経過した日数を保存すればいい。うるう年に関するルールは、タイムゾーンやタイムゾーンデータベースに関するルールよりずっとシンプルだし。この表現から年月日への変換は、コードで約50行あればできるよ。もちろん、日付の計算をしないなら、年、月、日をそれぞれ3つの数字で保存すればいいだけ。

さらに良いのは、ユーザーにテキストフィールドの代わりにカレンダー日付ピッカーを使わせることだね。これなら入力を完全にコントロールできる。

「02/18/1993」のフォーマットは、DD/MM/YYYYなのかMM/DD/YYYYなのか？18から判断すると後者だと思うけど、その規則は普遍的じゃないよね。あまりあいまいじゃないフォーマットとしてYYYY/MM/DDをおすすめするけど、完璧な答えはないな。

あなたの場合、日付の計算や大小比較はやらずに、等価性のテストだけをしてるんだよね？つまり、複合キーの一部ってことだ。僕も似たような問題に直面したことがあって、ユーザーが日付を提出するフォームがあったんだけど、タイムゾーンについてはあまり意識してなかったみたい。だから、「02/28/1993」を選んで、みんなが常に「02/28/1993」を見る限りはそれが正しいと考えたし、もし違うのを見たらそれは間違いだと思った。だから、システム全体でタイムゾーンを意識しない日付を使ったんだ。

Temporal[0]がこれをやるのが好きだな。君が扱ってたのはTemporal.PlainDate[1]、つまりカレンダーはあるけど時間やタイムゾーンはない日付だね（暗黙のうちに含まれてるかもしれないけど、誕生日みたいに関係ないこともある）。Temporalには他にも面白いタイプがあって、それぞれ異なる意味があるんだ：- Instant: カレンダーや場所に関係なく固定された時点。例えば「ユーザーがX日付と時間にログインした」みたいな感じで、どのタイムゾーンやカレンダーシステムでも有効。これが通常「Unix UTCタイムスタンプ」で使われるもの。- ZonedDateTime: Instantに似てるけど、特定のカレンダーと場所に関連付けられてる。Instantをカレンダーシステムとタイムゾーンに「リアル」に変換した感じで、ユーザーが意味のある時間を見れるようになってる。- PlainDate: さっき話したやつ。例えば誕生日とか。- PlainTime: 「毎日6:30pmにタスクを実行する」みたいな感じ。- PlainDateTime: Instantに似てるけどカレンダーシステムに関連付けられてて、タイムゾーンはない。ユーザーが日付ピッカーに入れるようなもので、タイムゾーンは暗黙的に含まれてる。- PlainYearMonth: 例えば「2025年10月にレポートを実行する」みたいな感じ。- PlainMonthDay: 例えば「私の誕生日は6月13日」みたいな。- Duration: 例えば「タスクは3時間30分実行された」みたいな。重要な概念も見てみてね[2]。[0] https://tc39.es/proposal-temporal/docs/ [1] https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate [2] https://tc39.es/proposal-temporal/docs/timezone.html

誕生日を扱う環境ってどんなとこなの？タイムゾーンを意識した日付や時間、間隔があるのに、すでに存在するナイーブ/プレーン/ローカルな日付タイプがなくて、文字列を使わざるを得ないって？その問題に対する合理的な解決策があるみたいだけど、そんな問題が最初にあるってのが意外だね。

通常の「法的」な日付はタイムスタンプやタイムゾーンに関連してないし、この事実は人間がソフトウェアを書く限り永遠に再発見されるだろうね。

医療がなぜ重要なのかを理解しているなら、これは本当に洞察に満ちてるね。私の知る限り、医療業界は基本的に誕生日をキーとして使ってる。これによって（a）他のプライマリーキー（名前や住所など）を持つ2人の患者を区別できたり、（b）患者にその値を言わせて、簡単に認知能力をチェックしたりできるんだ。

ただの文字列として保存すると、年齢に依存するロジックとか、フィールドのユーザーに解析ロジックを渡すことができなくなるよ。個人的には、FHIRは日付（生年月日を含む）に関してかなりいいシステムを持ってると思う：YYYY、YYYY-MM、またはYYYY-MM-DD。（正確な誕生日を知らないのは、国によってはよくあることだしね）。 https://build.fhir.org/datatypes.html#date

時計の数字が特定の数になったら寝なきゃいけない理由を考えるのって面白いよね。現代の技術なら、必要に応じて調整できるようにプログラムできるのに。火星人が今日の9:00amに寝て、明日の9:40amに起きることに技術的な理由はないし。農家がサマータイムを気にするのが滑稽だと思うのも同じで、知ってる農家は「夜明け」や「日没」の時間を基準にしてるからね。

Andorで「日」や「月」、「年」って言葉が出るたびに、銀河全体で意味が通じないことを考えないように脳をリセットしなきゃいけなかったよ。

その問題は今も存在してるけど、みんな頭を砂の中に突っ込んでるね。

え、じゃあ新年の一日は2025-01-01 - 2024-12-31 = 20250101 - 20241231 = 8870ってこと？つまり90ヶ月と10日、または7年6ヶ月と10日ってことだよね。それがどうして一日と同じなの？

メインフレームでは、ジュリアン日付がその理由で人気なんだ。YYDDD（年の日）。今日から30日後はいつ？25206+30

これに関しては特に問題ないと思うよ。むしろ面白いチャレンジだし、みんなに日本のカレンダー形式を理解してほしいな。知ってる人が多い方がいいからね！

ユーザーがそんな日付を入力するの？しない？じゃあ問題解決だね。DIYパースの利点は、ユーザーが扱いたいと思う入力のセットに制限して問題をシンプルにすることであって、一般的なライブラリを作ることじゃない。ジュニアにとっての正しい教訓は、物事を過剰に複雑にしないことだよ。

ISO8601のパーサーにこれを入れてみたけど、全然ダメだった。ISOにちゃんとした解決策を作るんじゃなくて、DIYで済ませてることを文句言ってやるつもり。

歴史的に体系的じゃないからだよ。エッジケースがいっぱいあるシステムなんだ。

残念ながら、業界の多くの人はタイムゾーン管理の一般的な落とし穴を理解してない。要件を設定する人たちも含めてね。「ユーザーのために毎週平日の午前2時に実行したい」と言って、単にそれをUTCオフセットとして保存して終わりにするのが典型的なパターン（ダジャレも含めて）。

タイムゾーンについて覚えておくべき本当に重要なことは、数学的な構造でも物理的な構造でも天文学的な構造でもないってこと。政治的な構造なんだ。その視点で見ると、自分のコードが実行される国の法律に依存する部分があるのと同じくらいの複雑さがあるよ。

「momentは素晴らしい」以外は全部同意だよ。開発者たちももう使うなって言ってるし、偶発的に変わった日付が原因でバグが出たアプリも何度も見てきた。Luxonはいいけどね。

でも、やっぱり時間について考えないといけないよね… ライブラリは本当に厄介な詳細を手助けしてくれるけど、高レベルな要件にもたくさんの落とし穴がある。例えば、スケジューリングアプリに関わったことがある人なら誰でも知ってる「今日のイベントのリストを取得する」ってやつ。で、「今日」って誰の「今日」？（タイムゾーン）サーバー、クライアント、ユーザーアカウントの設定？それとも、イベントの物理的な場所のタイムゾーン？そもそも「今日」って何を意味するの？日付を切り捨てるの？00:00-23:59？営業時間？「今日のイベント」って何を指すの？イベントは真夜中を跨ぐこともあるし… イベントは今日始まる必要があるの？今日終わる必要があるの？両方？イベントは複数の日に跨がることもある？楽しみは終わらないね！

ライブラリでは、タイムゾーンの厄介な部分を簡単にすることはできないよ。ほとんどの日付問題には「正しい答え」がたくさんあるし、それぞれの文脈によって求められるものが違うから、ライブラリは多くのことに対して意見を持てない。時間を扱うコードを書くなら、時間の仕組みを理解する必要があるよ。

特に、99.9999%の時間、特別なケースなんて全然気にしないし、ただユーザーにシンプルな日付を見せたいだけなんだよね。それでも、APIやサードパーティが変なことをやらかすせいで、問題にぶつかることがよくある。

moment.jsは、もう5年近く前から非推奨になってるよね？現代の代替品の中から選ぶのはおすすめしないな。

ぜひ書いてみて。けど、使わないでね。この警告は、ほとんどの場合、リリースするコードの文脈での話で、自分で学ぶための練習じゃないから。

難しいことをやりたい気持ちは分かるけど、バイナリで書くの？自分で電気を作るの？俺にとって一番大事な資源は時間なんだ。確かに、もっと低レベルな技術を学ぶこともできるし、時々それが役に立つこともある。でも、すでに解決された難しいことを自分流に再実装することに集中しても、何の価値を加えてるの？クライアントでライブラリやコードの書き方に興味を持ってる人には会ったことがないよ。壊れるまではね。壊れたら、誰が書いたかなんて気にせず、ただ動き出すことだけを気にするんだ。

こんなに物議を醸す意見だとは信じられない。自分で難しいことを解決するのは成長だよ。俺は100%同意する。新しいJSフレームワークを学ぶよりも、また収益を失うSaaSを立ち上げるよりも、難しい問題を自分で解決する方がいいよ。「成功」ってVCのおかげだし。何でもいいけど、限界を押し広げよう。

難しいことを学ぶ唯一の方法は、難しいことをやることだから、最も難しいことをやってみて。従業員に学ばせるためにお金を払いたくない、売れる成果を出してもらうために払いたいんだ。難しいことをやるのはいいけど、それが今までに誰もやったことがないこと、例えば月に行くことみたいな場合ね。すでに誰かがやったことを、自分がやってないからってやるのは良くないよ。エンターテインメントや自己成長のためならいいけど、それは自分の金でやるべき。エベレストに登ったり、南極に行ったりするのもそう。誰かのためにプロジェクトをやってるなら、個人的な欲望をプロジェクトに持ち込むのはダメだよ。

でも、苦労にはいろんな種類があるよね。結果として、問題の理解の仕方やナビゲートの仕方が変わることもあるし、純粋に同時進行の慣習の蓄積で難しくなることもある。全人類を調和させるためにみんなが幸せに合意するのは難しいからね。日付の扱いは後者にあたる。運よく掘り下げる方向に行けば、宇宙論的な考察にたどり着くこともあるけど、基本的にはカレンダーはめちゃくちゃだよ。

人は難しいことについてそう言うけど、俺は難しいことだけやりたいんだ。それは全然問題ないよ。自分の時間、自分の趣味だし。 > 簡単なことができる人なんて誰も求めてない、難しいことができる人が求められてる。いや、実際はそうじゃない。人は簡単なことができる人を求めてるんだ。無駄に難しいことをやらずに済む賢さがあるからね。君の愚かな考え方が、偶発的な複雑さや遅れたプロジェクトを生んでるんだよ。「賢く働け、ハードに働くな」って言葉もあるし。 > さあ、自分のデータライブラリやUnicodeフォントレンダリング、コンパイラ、OS、ゲームエンジン、他の人が「難しいからやるな」って言うことをやってみなよ。これを切り捨てて、これはLinkedInじゃないから。

このコメントはちょっと不思議だね。リンク先の記事のほとんどが、著者が自分で日付解析ライブラリを作ったことについて書いてるから。「自分でやるな」って部分は最初の数行だけで、正直言ってほとんどジョークみたいなもんだよ。この記事は、自分で日付解析ライブラリを書くなとは言ってないし、要するに「やるな。俺はやった。これが俺のやり方とその理由だ」って感じ。

「自分で実装するな」って見るたびに、自分でやりたくなるんだよね。学ぶためにやるのは有益だし、この一般的なフレーズの意図は、プロダクション環境で難しくて重要なものを「自分で実装するな」ってこと。俺は暗号学の仕事をしてて、学ぶためにいくつかのことを自分で実装してきたけど、実際に使うときは安定していて、フィールドテスト済みの暗号を使ってる。 > 難しいことについてはみんなそう言うけど、俺は難しいことだけやりたい。簡単なことができる人なんて誰も求めてないし、みんな難しいことができる人を求めてる。難しいことだけやりたいってのは、自分をかなり制限しちゃうよ。簡単に見えるけど改善できることはどうするの？俺は一時期、非技術系の医療製造の仕事をしてて、プロセスやツールを学ぶ時間を取った。その後、同僚（プログラミングやITの経験がない人たち）が使えるExcelやラボのコンピュータのVBAを使って、手作業でやってた在庫リストの準備を手伝うツールをいくつか実装したんだ。手作業だとグループ全体で3時間かかってたけど、俺のツールはボタン一つで5秒で終わった。今でも約10年後の今、使われ続けてるよ。これは「難しい」ことじゃなかった。いくつかのファイルをくっつけて、フィルターでリストをグループ化して、列でグループをソートして、読みやすくてマークしやすい印刷物を作っただけ。だけど、同僚たちは誰かが別のスキルセットを持って来るまで、これが可能だってことすら知らなかった。難しいことだけやるのは注意が必要だよ。他の人が何が難しいかを特定する必要があるから！それに、変わり者は難しいことだけやって、今までの解決策よりも良い解決策を見つけたと信じてる（相談したり、何が行われてきたかを学んだりせずに）。面白い人は、物事をそのまま学び（ほとんどのことにおいて専門家ではないという謙虚さを持って）、持っている知識を使って改善しようとする。自分の暗号を作る時間を無駄にするんじゃなくて、実際の「難しい」ことをやって、未解決のスペースを特定して、慎重で考慮された改善を行うべきだよ。

いくつかのことは、面白い分野に基づいた「良い難しさ」だと思う。よく設計されたツールやシステムを使って深く掘り下げたり、たくさんのクールなことを学んだりする。だけど、日付時刻関連のコードはその真逆だと思う。難しい部分は、現実の地理や政治、物理学/天文学に細かく従うことから来てる。そこから健全なモデルを抽出するための一貫性はなくて、特別なケースや恣意的なパラメータが積み重なってるだけ。もちろん挑戦は受け入れるけど、全てが同じなら「悪い難しさ」の仕事は他の人に任せておくのが嬉しいな。

さあ、自分のデートライブラリ、自分のUnicodeフォントレンダリング、コンパイラ、OS、ゲームエンジン、あるいは「難しいからやるな」と言われることをどんどん書いてみて。絶対にできるよ。気をつけるべきなのは、ほとんどの場合、これらをプロダクション品質のレベルで維持するのは才能あるエンジニアのフルタイムの仕事だってこと。だから、もし以下の条件があるなら、これに挑戦するべきじゃない。 - 達成したい高次の目標がある - プロダクション品質の実装が必要 もしそのどちらかが当てはまらないなら、思う存分やってみて。

オープンソースなら、そのSchemeコードを見てみたいな！

これで自分で日付パーシングライブラリを書く必要がなくなった。もし自分で日付パーシングライブラリを書いてたら、6つのISO 8601パーサーがあったけど、どれもダメだっただろうね。時間を無駄にしなかったことに感謝すべきだよ。

広く利用可能なdatetimeライブラリを使って、必要に応じてタイムスタンプをローカライズすることができる。でも、タイムスタンプは正規化されていて100%明確な方法で保存・送信されるべきだ。もし「タイムスタンプ」が過去の日付や決定的な未来の日付を意味するなら、同意するよ。（ただし、整数を使って文字列パースのステップを完全にスキップできるように、私はそれにはミリ秒のUnixエポックが好きだけど。）でも、未来の日付を扱う必要がある不運な場合、特に「壁の時計」（「2029年7月26日の午後1時にフランクフルトで会おう」）のような場合、タイムゾーンを知ることはできないよ。理由はいろいろあるけど、特にこの場合、EUがその時までに夏時間を廃止する可能性が高いからね。だから、正確でありたいなら、保存するタイムスタンプに地理的位置を含める必要があるよ。