エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
2038年問題とMySQLでの対策 - AnDeriensのブログ
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
2038年問題とMySQLでの対策 - AnDeriensのブログ
Monoar Rahman RonyによるPixabayからの画像 概要 2038年問題というのがあるらしい。 多くのケースで、t... Monoar Rahman RonyによるPixabayからの画像 概要 2038年問題というのがあるらしい。 多くのケースで、timestampが内部的には32ビットの符合付き整数で、2038年1月19日3時14分7秒(UTC)にその上限を迎える。 ja.wikipedia.org MySQLも例外ではなくtimestamp型を使っている場合、これにハマることになるとのこと。 LaravelのIlluminate\Database\Schema\Blueprint::timestamps もtimestamp型を使ってるので、Laravel使ってる人にもふつうに影響デカそうです。 対策 対策としては Datetime型を使う 整数型を使う という方法があるみたいです。 1. Datetime型を使う場合の注意点 DATETIME型は、タイムゾーンの影響を受けません。 そのため、タイムゾー