日付四方山話

Transcript

1. 日付関連四方山話 by がる
2. 自己紹介  古庄と申します  「がる(gallu)」というハンドルでふらついております  本職は技術者です。現役プログラマーやってます  バックエンド系なので、インフラとかDBとかも一通り  最近はPM業も多いですねぇ  あわせて、教育とか色々
3. 日付周りのネタを集めてみました  なんとなく考えていたら細かいネタが色々揃ったので  細かいのを連打したら「なんとかなるだろう」的にやって みたいと思います!!  気づいたら９個もお題があるので、サクサク進めていき ます!!
4. 1.日付のフォーマットは?  Atom (例: 2005-08-15T15:52:01+00:00)  HTTP Cookie (例: Monday, 15-Aug-2005 15:52:01 UTC)  ISO-8601 (例: 2005-08-15T15:52:01+0000)  RSS (例: Mon, 15 Aug 2005 15:52:01 +0000)  World Wide Web Consortium (例: 2005-08- 15T15:52:01+00:00)  などいろいろありますが……
5.  さて問題です: 年を2桁で省略するとして  04/05/06 これ、何年何月何日?  🇺🇸 アメリカ: 2006年4月5日に決まってるだろ、当然！  🇬🇧 イギリス:は？2006年5月4日ですけど？  🇯🇵 日本:えっ……2004年5月6日じゃ……ないんですか？  とりあえず  年は4桁で。二桁省略すんな  日付の区切りはハイフンで。それなら YYYY-MM-DD一択!
6. 2. ユリウス通日?  年月日、を「１つのint」で表せる!  日付の加減算とかループ処理とか、簡単!!  厳密には「小数をつけて時分秒を表せる」  基準点は「西暦 -4712年1月1日」  マイナスなんだ……  数値がでかくなるから「修正ユリウス日」ってのもある よ！  ユリウス通日から2,400,000.5を差し引いたもの
7.  例えば、今日の19:30(2025-04-23 19:30:00)だと  ユリウス通日: 2,460,788.93750  修正ユリウス日: 60,788.43750  PHPだと gregoriantojd() 関数で計算できるよ!!  逆にするなら jdtogregorian() も!!  「カレンダー 関数」だから --enable-calendar を指定して PHP をコンパイルする必要があるけどね!!
8. 3. JDT? JSTじゃなくて?  Japan Standard Time。日本標準時です  日本は、協定世界時(UTC)と比較して 9時間 進んでいます  基準点は明石市なんですって  JDT? typoでしょ?  いいえtypoではありません  話は少々変わりますが。サマータイムはご存じでしょう か?  聞いている限り「悪名高い」出来事をいろいろと伺います  2018年くらいになんか一瞬「サマータイム」とかお話が出 てきて「……なに言ってけつかるん?」とか思った記憶が
9.  さて時を遡ること1948年  「夏時刻法」なるものが生えてきました(Wikipedia から引用  夏時刻法（なつじこくほう、昭和23年法律第29号）は、1948年（昭和 23年）4月28日に公布・施行された日本の法律。夏時刻を実施するた めに制定されたが、1952年（昭和27年）4月11日に廃止された。  適用時間(こちらもWikipedia から引用  1948年（昭和23年） - 五月の第一土曜日の翌日（日曜日）（5月2日） から九月の第二土曜日（9月11日）まで （附則第二項）  1949年（昭和24年） - 四月の第一土曜日の翌日（日曜日）（4月3日） から九月の第二土曜日（9月10日）まで （本則）  1950年（昭和25年） - 五月の第一土曜日の翌日（日曜日）（5月7日） から九月の第二土曜日（9月9日）まで （改正法）  1951年（昭和26年） - 五月の第一土曜日の翌日（日曜日）（5月6日） から九月の第二土曜日（9月8日）まで （改正法）
10.  この「恐怖の刻限」に使われていたのが、JDTでございま す  Japan Daylight-saving Time の略だそうで  サザエさん(漫画)にも、「サンマータイム」って呼称で「時 計を進める」ネタが出ております  あと「処理済みフラグの大切さ」がわかるネタでもあります(笑  もし。あなたが。 万が一、1948年から1951年の間の夏頃の日付を扱うと き。もしかしたら、もしかしたら、JDTという亡霊に、遭遇 できる、かもしれません……
11. 4. 2000年問題を懐古する  Y2K問題とか略称までありました懐かしい(吐血  昔は「１バイト」のメモリが今よりとても重要で貴重なので ございました(吐血  だから「19xx年」の頭の19とか不要だし無駄なわけでご ざいます(吐血  1980年なら 80 でいいじゃん表示するときに頭に19つけ ればいいんだよ文字列脳(1900を足す、というint脳もござ いました) (吐血  これで1000レコードあったら2000バイトも省略できるんで すスバラシイ!!! (吐血  COPY句だと「05 YY PIC 99.」とか書いてたものです
12.  時は流れて……あれ、いつ頃から騒がれ始めたんです かねぇ? 1990年くらいにはあちこちで「対応する!!」なお話 が出ていたようには伺ってるんですが  「年二桁」が二桁で桁溢れすると激マズいでございます  1999年の次が1900年になりかねない!!  というわけで1990年代後半とか「駆け込み対応」とか  最悪「停電/水道の停止」「医療関連機器の停止等」「金 融系(銀行とか)の誤作動」まで想起される、ってんで必死 でございました  割と無事だったのは皆様の血と涙と汗と怒号と残業の成 果かと思われます(関係者各位、お疲れ様でした
13. 5. 「一ヶ月後」の危険性  「一ヶ月後」、strtotimeなら簡単でございます  echo date(DATE_ATOM, strtotime('+1 month')), "¥n";  DateTimeだったらこの通り  echo new DateTime()->add(new DateInterval('P1M')) ->format(DateTimeInterface::ATOM), "¥n";  今をときめくCarbonだったらこの通り  echo Carbon::now()->addMonths(1)->toAtomString() , "¥n";  簡単らくちん。  で終わるんならこんなパワポ作ってません
14.  さて質問「1月31日の一ヶ月後」は?  ↓ echo date(DATE_ATOM, strtotime('2025-01-31 +1 month')), "¥n"; echo new DateTime('2025-01-31')->add(new DateInterval('P1M')) ->format(DateTimeInterface::ATOM), "¥n"; echo new Carbon('2025-01-31')->addMonths(1)->toAtomString() , "¥n"; echo new Carbon('2025-01-31')->addMonth()->toAtomString() , "¥n"; 2025-03-03T00:00:00+09:00 2025-03-03T00:00:00+09:00 2025-03-03T00:00:00+09:00 2025-03-03T00:00:00+09:00
15.  割ときれいさっぱり全滅でございます  ここで燦然と輝くのが Carbon の addMonthsNoOverflow  echo new Carbon('2025-01-31') ->addMonthsNoOverflow(1)->toAtomString() , "¥n"; ↓  2025-02-28T00:00:00+09:00  素晴らしいでございます!!!!  ……続くよ
16.  一応念のため。「1月31日の二ヶ月後」は?  echo new Carbon('2025-01-31') ->addMonthsNoOverflow(2)->toAtomString() , "¥n"; ↓  2025-03-31T00:00:00+09:00  お見事でございます!!  ……まだ続くんだ
17.  もういっちょ。「1月31日の一ヶ月後の一ヶ月後」は?  echo new Carbon('2025-01-31') ->addMonthsNoOverflow(1) ->addMonthsNoOverflow(1)->toAtomString() , "¥n"; ↓  2025-03-28T00:00:00+09:00  なぜ頑張れなかった orz  無茶言うなや
18.  結論 「一ヶ月後」やめれ。日付で語れ  マジで一番事故率が低いです  「30日後」なら、どの手段使っても確実に安全だよ?  「翌月」が欲しいだけなら、日付を1日固定にするとよいです
19. 6. 昭和100年問題  古き良き時代、昭和  いやそうじゃなくて  古いんだけどあんまりよくないネタ「昭和100年問題」  ただ思ったほど起爆しませんでしたねぇ  古い頃は「１バイトが貴重」でございました(Y2Kでやった  日本は割と「和暦」でデータを持つところもございました  昭和なら2桁(2バイト)あれば余裕じゃんヤッタネ!!  「平成から令和」と違い、「昭和から平成」は、割とどった んばったんした頃合いでございました  詳しく書くと不敬になりそうなんで適宜ググってください
20.  システム改修をせにゃならん、のではあったのですが  色々あったとは思うのですが、こんな「みょうあん」が浮 かんだところが、まぁそれなりにあったようでございます  内部的には「昭和n年」をそのまま持ち続けて。表示のときは、 64以上なら、63を引いて「平成」って頭につければよくね?  でまぁとりあえず「当座をしのぐ」のはよかったんですが  西暦2025年(今年だよ)、「昭和100年」にあたるのでござ います  ん? 桁数、二桁言うてなかったっけ? あふれない?  以下略(あんまり起爆しなかったし)  いやまぁ今年の年始、ちょいと警戒はしていたのですが
21. 7. 2038年問題  桁があふれる問題シリーズ、当面のラストでございます  さてコンピュータ内部では「UNIXタイム」で時刻をカウント しております  いろいろな呼び名があるよねぇ  1970-01-01 00:00:00 が起点でございます  おいちゃんの生まれ年なんで個人的には覚えやすい(笑  2025-04-23T19:30:00+0900 は 1,745,404,200 です(17億……)
22.  お話はそれますが、元々の(C言語の)intのサイズは様々 でございます  おいちゃんが昔の頃は16bitとかございました(笑  signedで、最大が 32,767 でございます  世の中は64bitが多ございますが、まだ32bitも健在かと 存じ上げます  32bit signed で 2,147,483,647(21億ちょい)  64bit signed で 18,446,744,073,709,551,615(1844京ってなに?
23.  さて、日本で例えば 2038年1月19日12時14分6秒 なの ですが。strtotimeを使って計算をしてみますと  2,147,483,646  2,147,483,647(参考: 32bit signed 最大値  はて?  なお「桁あふれ」すると(PHPと違って)オーバーフローす るので「ものすごいマイナスの値」になります  PHPはfloatになりますよね(それも凄い仕様かと思いますが)  というわけで、1900年くらいにいきなり日付が「バック・ トゥ・ザ・フューチャー」します!
24.  まぁ全ての機器が64bit intになってりゃいいんですが  実際、どうなるんですかねぇ?  今「お若い」世代の皆様は、多分「脂がのった」頃に遭遇 しそうなので、是非いまから警戒をしておいてくださいま せませ
25. 8. MySQLの日付問題  とりあえずMySQL使ってるなら「timestamp使うな datetime使え」ってお話から  理由は「2038年問題に引っかかるから」  きれいな前振りだったともいえる(笑  「TIMESTAMP データ型は、日付と時間の両方の部分を含む 値に使用されます。 TIMESTAMP には、'1970-01-01 00:00:01' UTC から '2038-01-19 03:14:07' UTC の範囲があり ます。」 by MySQLのマニュアル
26.  もう一つやっかいなのが「タイムゾーンが保持できない」 問題  PostgreSQLは(データ型にもよるが)持てるんだ  いや「日本でしか使わない」サービスなら基本さほど問 題ないんですが  時々「タイムゾーンUTC」のまま運用していて、create_atとか が謎い時間になっていて……なんてことが検閲削除  「複数のタイムゾーンにまたがる」サービスの時とか、面 倒が深いんですよねぇ  真っ当にいくなら「UTCにして保存」「出力は適宜」  個人的には「BIGINT型にしてUNIX時間」をやってみたい(笑
27. 9. 不定時法のお話  荒みそうなお話が多かったんで最後くらいはきれい目な ネタを  明け六つ暮れ六つとか丑三つ時とかおやつ(八つ時)と か一時(いっとき)とか、日本人には割と(言葉だけは)なじ みがあるんじゃなかろうか? と  その辺を、ちょいとつれづれにお話したいと思います  時間、間に合うかなぁ?
28.  「日の出」と「日の入り」を基準にして6つに分割します。 んで、分割した１つを「一刻」といいます  春分の日と秋分の日だと「どちらも12時間」なので、6分 割して「全部2時間」となるのですが  夏は日中が長く、冬は夜が長いので。一刻は、季節に よって昼と夜で長さが変わってきます  だから不定時法 いいます
29.  日の出のタイミングが「卯(う)の刻六つ(明け六つ)」、日の 入りのタイミングが「酉(とり)の刻六つ(暮れ六つ)」となり ます  そこから「五つ」「四つ」で「九つ」「八つ」「七つ」となります  明け六つから、朝五つ、昼四つ、真昼九つ、昼八つ、夕七つ 暮れ六つ、宵(よい)五つ、夜四つ、真夜九つ、夜八つ、暁七つ  ほかに干支(十二支)も使われてました  子(ね)が真夜中(九つ)から始まります。正午が「午」です
30.  一刻は前述した通り「大体2時間くらい」でした。例えば 「六つ」から「五つ」になるまで、が一刻です  「半刻(はんとき)」で1時間程度、「四半刻」で30分程度  この「四半刻」をつかって、一刻を四分割して「一つ時」から「四つ時」 までの時をカウントする方法もありました  丑三つ時は「丑の刻八つ、の、(四半刻の)三つ時」  丑の刻八つは大体AM1～3時。三つ時なので+60分で、大体2時
31.  さて不定時報を「PHPで組みたいなぁ」と思ってたら、面 白い関数を教わりました  date_sunrise(): 指定した日付と場所についての日の出時刻を 返す  date_sunset():指定した日付と場所についての日の入り時刻を 返す  疑問: なぜ標準で存在している? (笑  「日付・時刻 関数」なんで「PHP コアに含まれるため、 追加の インストール無しで使用できます。」(笑
32.  なお「PHP 8.1.0 で 非推奨 になります」とのことです  でも安心  date_sun_info():日の出/日の入り時刻と薄明かり (twilight) の開始/終了時刻の情報を含む配列を返す  なんかパワーアップした(笑  というわけで皆さんも「不定時法」のコードを気軽に書い てみましょう!!
33. まとめ  日付の小ネタ……のつもりです本人  笑ったりちょっと怖かったりしていただければ幸いです  ここまでちゃんとしゃべれたかな?