36日目です。
本日から、見てもらう人が分かりやすいように、より簡潔な文章を書くよう変えていきます。（見返してみると文字が多い、かつ冗長になっているので非常に見づらい、、、）

2038年問題とは

2038年1月19日午前3時14分7秒（日本時間は+9時間）を過ぎると、（時刻を正しく扱えることを前提としたコードがあれば、）プログラムが誤作動する問題のこと。

なぜ調べたか？

同期が「データベース設計で2038年問題があるからTIMESTAMP型は使わない方が良いらしい」と言っていて、個人でアプリ作るならもちろんDB設計をするわけだし、知っとかなきゃ！となったためです。

なぜ誤作動を起こすのか

2038年1月19日午前3時14分7秒を過ぎると、ラップアラウンドを起こし、値が負として扱われるため。
従来のシステムが時刻を符号付32ビットで実装されていた為、最大で取り扱えるのは2,147,483,647秒（約68年）までに限られていた。スタートは協定世界時（現在使われている標準時。1970年1月1日0時0分0秒が基準）であり、そこから2,147,483,647秒後の上記の時刻を過ぎると、下記のようになる。

上から
2進数
10進数
本来の時刻
誤った時刻

01111111 11111111 11111111 11111111
2,147,483,647
2038-01-19-03:14:07
2038-01-19-03:14:07
※最後の正しい秒数

10000000 00000000 00000000 00000000
-2,147,483,648
2038-01-19-03:14:08
1901-12-13 20:45:52
※変わった瞬間（誤った時間）

10000000 00000000 00000000 00000001
-2,147,483,647
2038-01-19-03:14:09
1901-12-13 20:45:53
※変わった瞬間＋1秒

※ラップアラウンド
処理可能な範囲の最後に達した後に、最初に戻ること。8ビットで管理している情報であれば、255の次が0になること。

対策

Rubyもかつてこの制限を受けていたが、Ruby1.9.2からはなくなったとのこと！なので、Ruby単体の場合は問題になることはないそうです。ただ、MySQLでは影響を受けるそうなので、その際はTIMESTAMP型ではなく、DATETIME型に切り替えることが求められる（DATETIME型であれば9999年12月31日23時59分59秒まで求められる）。

所感

IT業界で働く上では常識として、専門外の方に「なぜ問題なのか」簡単に説明できるようになっておくべきだと感じました。
wikipediaにあるように「32ビットの符号2進表現におけるラップアラウンドという理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある」ため、なぜ2038年問題を騒いでいるのか理解されないまま18年後に大規模なシステムエラーなど発生する可能性もあるためです。

参考：

MySQLで timestamp型を使うのはNG！2038年問題の対処法 | PisukeCode - Web開発まとめ

2038年問題 - Wikipedia

MySQL :: MySQL 5.6 リファレンスマニュアル :: 11.3.1 DATE、DATETIME、および TIMESTAMP 型

本日チャットアプリのチャット画面の見た目がやっと完成しました（計25時間くらい。笑）
目安時間も25時間だったので、目安通りで終わったのかと思ったら救い？ですが、二度と見た目だけでこんなに時間かけたくないですね、、

そして本日、ブログ投稿アプリの課題が課されたので、作り始めました（今週金曜日に発表会があるので期限はそれまで）。
全て一から自分で作るので、最初は手が動きませんでしたが、「rails new」をした瞬間からすごい楽しくなりました。
特に、何が必要なのかを考えてる瞬間が楽しいですね。
物作りっていいですね。
CSSのフレームワーク「Materialize.css」の存在も知ったので、明日は弄り倒します笑