「2038年問題」について、現実のものとして考える時期が来たのかもしれない「2000年問題よりはるかに深刻」「映らないテレビとか出てくると思う」
上原 哲太郎/Tetsu. Uehara @tetsutalow ソフトハウスバイト→同経営→京大助手→和歌山大講師→京大助教授→同准教授→総務省で役人→立命館大学教授。その間NPOやってたり。得意分野はシステム管理とか情報セキュリティとかデジタルフォレンジックとか情報教育とかですがICTだいたいどこにでも突っ込みます。でも私のつぶやきは組織の公式見解とは無関係です。 uehara.tetsutaro.jp 上原 哲太郎/Tetsu. Uehara @tetsutalow 当研究室では2038年問題を追いかけていますが、この度論文が出ました。 doi.org/10.20729/00239… 「32bitを超えるtime_t型を持つ環境における2038年問題とその検出」 関連して本研究で開発したツールを含むDockerイメージを配布開始しました。合わせてご活用下さい。 github.com/
「gettyimages」より 一部システムが2038年1月19日3時14分8秒以降の時刻になると誤作動を起こす可能性があるとされる「西暦2038年問題」。新たな論文が発表され、一般的に想定されているより広い範囲で大きな影響が出るのではないかという声が広まっている。どのような規模の影響の発生が想定されるのか。また、システム運用者はどのような対策をすべきなのか。9月に論文「32bitを超えるtime_t型を持つ環境における2038年問題とその検出」を発表した立命館情報理工学部教授の上原哲太郎氏に聞いた。 2038年問題とは、LinuxなどのUNIX環境、C言語プログラムのUNIX timeで表現されたタイムスタンプ値が32bit符号付き整数型で定義されている場合、2038年1月19日3時14分8秒以降の時刻で整数オーバーフローが生じ、それを参照したシステムが不具合・障害を起こすというもの。対
2038年問題 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "2038年問題" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2015年7月) 上から、2進・十進・問題のある時刻・正しい時刻。（GIFアニメ）3時14分7秒を超えたところで負の値となり、時刻に狂いが生じる恐れがある。 コンピュータおよびコンピュータプログラムにおける時刻の表現として「UNIX時間」《協定世界時における1970年1月1日0時0分0秒からの経過秒数[注釈 1]》を採用しているシステムがある。 UNIXおよびUNIX派生のオペレーティングシステム (OS) における基幹ソフトウェア部品の多くはC言語で書かれているが、前述
System call conversion for year 2038 [LWN.net] lwn.netでLinuxカーネルを2038年問題に対応させるにはという記事が公開されている。 32bit版Linuxカーネルのtime_tはsigned 32 bitなので、現行の32bit版Linuxカーネルをそのまま使い続けるシステムは、2038年問題の影響を受ける。 問題の日付が近づくにつれ、32bitシステムは様々な楽しげな理由により障害を起こすことが予測されるので、今日のLWN読者は、退職から呼び戻されて、紀南を救うために英雄的な活躍をするだろう。今対策をしなければの話だが。 さて、32bit Linuxカーネルでも、time_tなどの時間の表現に64bitの値を使えば2038年問題は解決できるか。実は、問題はそれほど単純ではない。 カーネル内部の時間表現を64bitに移行するだけでは
ゲームの「10年プレイしない」実績解除のために時間をすっ飛ばした結果「2038年問題」にぶつかってSteamのフォント表示が大混乱
PCゲームのダウンロード販売・ストリーミングプレイのプラットフォームであるSteamで、表示されるテキストが突然ランダムなフォントになるという報告が話題になりました。その報告をしたユーザーによると、フォントがランダムに変化した原因には「2038年問題」が影響していたとのことで、その経緯と結果に注目が集まっています。 The stupidest shit just happened to me: @Steam started picking a random font I had in my user fonts dir: FG Virgil, the @excalidraw font. I have no idea why, but this is wild... pic.twitter.com/IDRqRwFs1s— bµg (@insouris) 2022年10月8日 Investig
まず2038年問題というのをご存じでしょうか 2038年問題 - Wikipedia 2038年問題（にせんさんじゅうはちねんもんだい）は、2038年1月19日3時14分7秒（UTC、以下同様）を過ぎると、コンピュータが誤動作する可能性があるとされる年問題。 http://ja.wikipedia.org/wiki/2038%E5%B9%B4%E5%95%8F%E9%A1%8C C言語で epoch を扱う time_t が32bit OS上でオーバーフローし日本時間2038/01/19 12:14:07の次に1901/12/14 05:45:52が来てしまうという問題です。まぁそもそも2038年にもなって32bit OSを使っている側が悪いと言えばアレですが。 実際にどんな事が起きるかは、32bit OS上で以下を実行すれば分かる。 #include <stdio.h> #include
3. 主に北米と欧州で実施 By Paul Eggert CC-BY-SA-3.0, via Wikimedia Commons 実施中 過去に 実施 実施経験 なし 5. 繰り返す導入論 • 高度成長期：エネルギー不足で導入論が高まる • 1990年代から繰り返す…日経見ると • 1995年3月4日 「サマータイム、立法化の動き強まる」 • 1999年2月23日 「参院の超党派議連、サマータイム２００１年度導入、議員立法提出へ。」 • 2001年4月18日 「サマータイム、２００３年導入へ、環境省、法案を来年提出」 • 2004年9月25日 「サマータイム法案提出へ。」 • 2005年4月27日 「サマータイム法案、今国会に提出へ――自公が合意、２００７年導入めざす。」 • 2008年5月30日 サマータイム「１０年導入を」、超党派で法案提出へ、省エネ・経済効果見込む。 • 2008年は
2038年問題はUNIX時間のオーバーフローに伴ってプログラムが誤動作するというものですが、既にほとんどのプログラムで解決済みとされています。しかし、ゲーム開発エンジニアのエイドリアンさんがMicrosoftのドキュメント上に2038年問題を引き起こすコードが掲載されているのを発見。そのコードをコピーしたプログラムでは2038年問題が発生してしまうと警告を行っています。 Year 2038 problem is still alive and well | Silent’s Blog https://cookieplmonster.github.io/2022/02/17/year-2038-problem/ UNIX系のOSでは時刻情報を扱う際に1970年1月1日0時0分からの経過秒数として表される「UNIX時間」を利用しています。かつて、UNIX時間はシステム内部において符号付き32ビ
headless曰く、 Linuxカーネル5.6（Linuxカーネル5.4/5.5にバックポートされる可能性も高い）の32ビット版で2038年問題（Y2038）への対応が初めて行われたという（Arnd Bergmann氏のメーリングリスト投稿、Phoronix、The Register）。 Y2038はUNIX時間が2038年1月19日3時14分7秒（UTC）以降、符号付き32ビット整数で表現できる範囲を超えてしまうという問題だ。OpenBSDは2014年にY2038対応しているが、Linuxの場合64ビットシステムでは64ビット整数が標準のため影響は少ないものの、カーネルとユーザー空間が分かれていることから32ビットシステムでの対応は簡単に進められる問題ではなかったという。なお、2038年に32ビットPCが使われていない可能性は高いが、32ビットの埋め込みシステムが多数残っている可能性も
Ubuntu Weekly Topics Ubuntuにおける2038年問題との戦い・暗号化設定の調整、SmartNICとUbuntu Ubuntuにおける2038年問題との戦い・暗号化設定の調整 Foundation Teamの開発レポートを見ると、いくつか興味深い作業を読み取ることができます。まず注目するべきはarmhf time_tという見出しのついた作業を、複数のエンジニアが進めている点です。これは内容からして「2038年問題への対応（32bit Arm）」であろうことがわかります。この文脈で2038年問題について知っておくべきこととしては次の通りです。 伝統的なUnix環境では、システム時刻はepoch time（1970年1月1日午前0時0分0秒）からの経過秒数で保持している。この系において、整数オーバーフローによる巻き戻りが発生すると、「時刻が突然1970年に巻き戻
OpenBSD開発チームは5月1日、UNIX系OSの最新安定版「OpenBSD 5.5」をリリースした。2038年問題に対応するためのtime_t型の64ビット化が行われている。 OpenBSDはセキュリティや安定性、移植性の高さなどを特徴とする4.4BSDベースのUNIX系OS。i386やsparc/sparc64、arm、alpha、powerpcなど多数のアーキテクチャに対応する。 年2回のリリースサイクルで開発が進められており、2013年11月1日に公開された「OpenBSD 5.4」に続くリリースとなる。恒例の「リリースソング」は「Wrap in Time」。 本バージョンでの大きなトピックとして、2038年問題への対応がある。主としてUNIXでは32ビット符号付き整数型であるtime_t型を使って1970年1月1日からの経過秒数を扱っているが、2038年1月19日3時14分7秒
tldr; これの詳しい話. また, オンラインでも変換できることを示す. 検証結果: XFS全体フラグのbigtimeを立てても, 古いinode内のフラグはbigtime=0でタイムスタンプのバイナリもそのまま. 新しいinodeはbigtime=1で新しいフォーマットになる. 次に古いinodeをtouchしたらbigtime=1になって, フォーマットも変わる. https://t.co/QPSsKcfisD— イーロン・マスクツイッターやめろ (@naota344) 2024年10月16日 XFSのbigtimeとは? XFSのタイムスタンプは現状では, signed 32bitがUNIXエポックタイム(1970年1月1日 00:00:00 UTC)からの秒数で, 32bitがナノ秒部分となっています. これだと2038年以後の日時を表現できなくなります. そこで, その2つのフ
8. 2038年問題
32ビットPCでは数値を扱う限界があります。 PHPで日付を扱う事が多いと思いますが、UNIXタイムスタンプを利用すると数値 の限界に引っかかる事を知っておく必要があります。 32ビットPCで扱う数値限界は 2の31乗－1 で、 2147483647 です。 これをUNIXタイムとして日付に直すと、 <?php $unixtime_max = pow(2, 31) - 1; echo date('Y-m-d H:i:s', $unixtime_max) . "\n"; $unixtime_overflow = $unixtime_max + 1; echo date('Y-m-d H:i:s', $unixtime_overflow) . "\n"; ?> 2038-01-19 12:14:07 1901-12-14 05:45:52 となり、2038-01-19 12:14:07 以降の
Debianプロジェクトのプロジェクトリーダー Steve Langasekは2月2日、Debian開発者向けメーリングリストに「64-bit time_t transition in progress」というタイトルで投稿し、2038年問題（Y2038）に対応するための作業の進捗について報告を行った。Debianは現在、2025年以降のリリースが予定されている「Debian 13 "Trixie"」の32ビットアーキテクチャが2038年以降も動作できるように取り組んでおり、とくに32ビットarmアーキテクチャへの対応にフォーカスすることを明らかにしている。 64-bit time_t transition in progress -lists.debian.org C言語で時間を表現するための型として使われている「time_t」は、世界標準時で1970年1月1日午前0時0分0秒からの経過
time_t と 2038年問題
Shinji Kono @shinji_kono OS が64bit なのと time_t の問題は独立だから、2038年問題とは直接は関係しない。sizeof(time_t) =4 なOSを見つけるのは、もはや難しいんじゃないかなぁ。 2013-03-24 12:51:50
PHPによる2038年問題対応:phpspot開発日誌
【PHP TIPS】 8. 2038年問題：ITpro Calcクラスを使うと速度が遅くなってしまいますがUNIXタイムを扱いませんので、子孫にやさしいコーディングを行う事が出来ます。 PHPによる2038年問題対応。 PHPで time 関数などによってUNIXタイムを使っている人も多いはずです。 この関数では、「1171206000」のように10桁の「1970年1月1日 00:00:00 GMT」からの秒数を返します。 この10桁では、2038年以降の日付を表すことは出来ません。9999999999の次は0となってしまい、また1970年1月1日となってしまいます。 そこで、Pear::Dateの使い方が紹介されてます。 使い方は次のようにそんなに難しいものではないので、2038年以降も扱うプログラムを書く場合はこのモジュールを使いましょう。 <?php require_once "Da
いわゆるコンピュータの“西暦2038年問題”といわれる事象が日本で発生し、日常生活に影響を与えたことが明らかになった。2038年問題による日常生活への影響が確認されたのは、世界でもほぼ初めて。 コンピュータの西暦2038年問題とは、C言語を使って開発したシステムをUNIX環境で利用している場合に、グリニッジ標準時の2038年1月19日3時14分8秒を過ぎると、システムが正しく時刻を認識できなくなる問題を指す。 UNIX環境では、システム内部の時刻をグリニッジ標準時（GMT）1970年1月1日0時0分0秒からの経過秒数で保持している。経過秒数で表す時刻データに、4バイトの符号付き整数を使っている場合には、2038年1月19日を過ぎると、本来数字の正負を判断するために使う部分まで時刻を表示するために使わざるを得なくなる。その結果、正しい時刻を認識できなくなるのである。 2038年問題による影響
ログインするときにログインの状態を保持するチェックボックスがあると思います。以前開発したシステムで急にそのログイン状態を保持するのが利かなくなったと連絡があり調査したところ、原因は2038年問題でした。 ログインするときにログインを保持するにチェックがあると session_set_cookie_params(60*60*24*365*30); として30年後を指定していました。 しかし、2038年問題 – Wikipedia にあるように2038年1月19日 3時14分7秒でオーバーフローしてしまうため、クッキーの有効期限が0を指定したときと同じ扱いになってしまいました。 Firefox のオプションで Cookie の有効期限を毎回確認するにして確認すると、その時点で既にブラウザを閉じるまでになっていました。 2038年問題は知っていましたが気がつくのが遅く、しばらく気がつきませんでし
現在の Unix システムでの最大時刻は、協定世界時の2038年1月19日午前3時14分7秒です。 http://www.ruby-lang.org/ja/man/?cmd=view;name=Time Timeは2038/1/19以降がエラーになる。 >> Time.gm(2038,1,19).strftime("%Y-%m-%d %a") => "2038-01-19 Tue" >> Time.gm(2038,1,20).strftime("%Y-%m-%d %a") ArgumentError: time out of range from (irb):7:in `gm' from (irb):7 from :0DateTimeはもっとずっと先まで大丈夫。 >> require 'date' => true >> DateTime.civil(2038,1,19).strftime(
2038年問題
32ビットPCでは数値を扱う限界があります。 PHPで日付を扱う事が多いと思いますが、UNIXタイムスタンプを利用すると数値 の限界に引っかかる事を知っておく必要があります。 【PHP TIPS】 8. 2038年問題：ITpro エントリではPEAR::Dateが紹介されていますが、ここでは別の方法を。 5.2.0以降になりますが、組み込みクラスのDateTimeクラスならこの問題に対応しています。 <?php $date = new DateTime('2038-1-19 12:14:07'); echo $date->format('Y/m/d H:i:s') . PHP_EOL; $date->modify("+1 day"); echo $date->format('Y/m/d H:i:s') . PHP_EOL; $date->setDate(3000,12,31); echo
西暦2038年1月19日3時14分7秒を過ぎたら、Docker環境では何が起こるのか？ 前回に挙げた5つの疑問のうち、最後の疑問5はDockerの2038年問題です。実際に、2038年1月19日3時14分7秒を過ぎたらDockerコンテナがどうなるのかを見てみましょう。 Dockerエンジンが稼働するホストOSを2038年にセットする前に、まずは準備として、必要なDockerイメージを2つ入手しておきます。時刻を2038年にセットした後では、Dockerイメージの入手に失敗する可能性がありますので、この時点で入手しておきます。32ビット版のDockerイメージ「tenforward/centos-i386」と比較のための64ビット版CentOS 6.8のDockerイメージ「centos:centos6.8」を入手し、ホストOS上に保存しておきます。
UNIX TIMEを用いるメリットは何でしょうか？2038年問題などの問題もあり、今の時代に敢えて使用するメリットがわかりません。…
UNIX TIMEを用いるメリットは何でしょうか？2038年問題などの問題もあり、今の時代に敢えて使用するメリットがわかりません。昔はメリットとされたこと、今後も他の形式（文字列型、日付型など）を使用するよりもメリットとなることを教えてください。私自身が漠然と不思議に思ったことなので、どういった視点からの回答でも構いません。
第25回 32ビット環境に迫る「2038年問題」 時計がおかしくなると……：古賀政純の「攻めのITのためのDocker塾」（1/3 ページ） いまだ数多くのシステムで32ビットのOSやアプリケーションが使われていますが、実は深刻な影響が懸念される「2038年問題」を抱えています。将来どのような影響が出るのかについて、今回から「Docker」による検証を先取りしていきます。 連載の第13回と第14回では、古いシステムからの移行や延命措置を取り上げてきましたが、実はいずれも64ビット環境を想定したものでした。しかし、日本で稼働するシステムには古い「32ビットアプリ」が数多く存在し、深刻な影響が懸念される「2038年問題」を抱えています。IoT時代の到来を見据えてアプリが全て64ビット対応になれば話は単純なのですが、32ビットのOSやアプリの現役ぶりはまだまだ続きそうです。そこで今回からは、Do
皆さんこんにちは。R&D事業部 チャンウクです。 今日付け、すなわちこの投稿でブロガーデビューさせていただきます。 私の投稿では主にシステム開発時のエピソードや勉強内容についてお話したいと思います。 さて、皆さん、「2038年問題」はご存知でしょうか。 初耳の方もいらっしゃると思いますが、 今回は世間に2038年問題として知られているバグを処理、解決した事例を紹介します。 ■ 概要 今、R&Dでは社内で使う 【業務支援ツール】を開発しております。 全社員の日々の業務を扱うため、カレンダーを使ったページが多いです。 ■ 問題発見 実装したカレンダーの単体テストを行っている際、こんな表示がでました。 !?!? 2038年1月の次は、1970年1月!? 一体どうしたものでしょうか。 分析してみましょう！ ■ 原因分析 業務支援ツール開発では、日付の調整をするためにPHP（Web開発でよく使用され
第26回 32ビット環境に迫る「2038年問題」 検証における5つの疑問：古賀政純の「攻めのITのためのDocker塾」（1/4 ページ） 前回は32ビット環境に忍び寄る「2038年問題」に触れました。Dockerを使った仮想環境での延命措置も期待されますが、実際のところはどうなのでしょうか。今回はその検証に向けた考察をしてみます。 32ビットのOS環境をLinuxのDocker環境で稼働させることができるのか？ 32ビットOSの環境をDockerの環境で稼働させることは、果たして可能なのでしょうか。そのためには、32ビットのOS環境自体が64ビット版Dockerの環境で稼働するのかどうかを確認しなければなりません。Dockerによって、古い32ビット環境を2038年まで使い続けるのは現実的ではありませんが、稼働が技術的に可能かどうかを知っておく必要があります。 32ビット環境がすぐになく
/.Jなら詳細な説明は省いても大丈夫と思われる2038年問題の発生まで、日本時間9月13日6:00（UTC9月12日21:00）にてあと8億秒となった（カウントダウンページ）。上記wikipedia記事によると、 2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系やOSのAPIといったシステムの深いレイヤに潜む問題である。 「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある。2000年問題のように暦年の変わり目というキリのよいときに地域の標準時に応じて順次に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資源の確保がより困難となる可能性がある。
「2038年問題」への対応進むLinux
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 村上雅章 野崎裕子 2020-02-21 06:30 2038年1月19日（火）の協定世界時（UTC）午前3時14分8秒に世界は終焉（しゅうえん）を迎える。と言ってもこれは「ヨハネの黙示録」に記されているような意味合いのものではない。この時点から、Linuxや旧版の「macOS」といった、32ビット版のUNIXベースのOSが使用している時刻の保存領域が桁あふれを起こす結果、負の数値を刻み始めるのだ。これは良いことではない。こういったOSが稼働している32ビットコンピューターは誤動作するだろう。だが幸いなことに、Linuxの開発者らは既に準備を整えている。 この問題は、UNIXにおける時刻の計数方法に端を発している。UNIXとその親戚筋にあたるOS、つまりLinuxやmacOS、その
Linux Daily Topics 2019年5月7日Linux 5.1がリリース、新しい非同期I/Oインタフェース、2038年問題対策など Linus Torvaldsは5月5日（米国時間）、「Linux 5.1」の正式公開をアナウンスした。約2ヵ月の開発期間と合計7本のリリース候補（RC）版を経ての公開となる。 Linux 5.1 :Linus Torvalds Linux 5.1におけるおもな変更点は以下の通り。 バッファあり／なしの両方をサポートするハイパフォーマンスな非同期I/Oインタフェース「io_uring」 ファイルシステムの変更を監視する「fanotify」に再帰的な監視を可能にする「Super block root watch」機能を追加 /proc/pidからファイルディスクリプタを取得し、再利用されるプロセスID（PID）を安全に呼び出す NVDIMMなどパ
2038年問題とは - IT用語辞典
概要 2038年問題（year 2038 problem）とは、西暦2038年のある瞬間を境に一部のコンピュータシステムが誤作動する可能性がある問題。古い設計のシステムが採用している日付と時刻の標準データ形式が定義上の上限値を超えてしまうために起きる。 古いUNIX系OSやC言語では、時刻を協定世界時（UTC）1970年1月1日午前0時からの経過秒数（いわゆるUNIX時間）で管理している。この値のデータ型（time_t型）はもともと32ビットの符号付き整数で実装されていたため、上限値である21億4748万3647秒を超える未来の日付・時刻は表現することができない。 経過秒数がこの上限を超えるのは（うるう秒を考慮しなければ）協定世界時の2038年1月19日午前3時14分8秒（日本時間では同日の午後12時14分8秒）であり、この形式で時刻を管理しているシステムはそれまでに対策を施さなければこの
2038年問題へのカウントダウン
2038年問題カウントダウン時計 世界標準時:2038年1月19日3時14分8秒(日本時間:12時14分8秒) C言語は通常時刻を1970年1月1日0:00を起点に2進数で頭の一桁を±に残り31桁を経過時間（単位 秒）の計32桁で表しています。 そのため、起点から2,147,483,647秒たったこの日のこの時間以降に値がおかしくなり（1900年）エラーが起こる可能性があります。 因みに、2004年1月、ATMにこれを原因とする障害が発生しました。 --詳しい説明-- C言語で時間は1970年元日0時からの経過秒数を符号付32bitで表します。 符号付32bitだと一番上の桁を±に使用する（＋なら0、－なら1）ため
エフセキュアブログ : 2038年問題
2038年問題 2013年01月20日04:53 ツイート mikko_hypponen ヘルシンキ発 by：ミッコ・ヒッポネン 本日は2013年1月19日だ。つまり2038年1月19日は、今からちょうど25年後であることを意味する。 その日がなぜ重要か？2038年1月19日03:14:07（UTC）に我々は2038年問題に突入するのだ。 数多くのUnixベースのシステムは、この時点以降の日付を扱えない。たとえば、現在の一般的なUnixベースの電話機に、2038年以降の日にちは設定できない。これは我々が試したiPhoneとAndroid端末のすべてに当てはまる（iOSはBSDベース、AndroidはLinuxベースだ）。もちろん、これはWindows Phoneには当てはまらず、3000年まで任意の日付をセットできる。 そう、25年はずっと先だ。しかしUnixベースのシステムは、その時に
日付・時刻関数の2038年問題
従来からあるdate関数などの日付・時刻関数は、32ビットコンピュータでは2038年頃に限界がきます。「PHP入門」という点では今すぐ大問題になるわけではありませんが、実社会ではもう少し早く問題が発生する場合があります。 <?php for ($i = 2147483640; $i < 2147483650; $i++) { echo date("Y/m/d H:i:s", $i) . "<br />"; } ?> ○実行結果 2038/01/19 12:14:00 2038/01/19 12:14:01 2038/01/19 12:14:02 2038/01/19 12:14:03 2038/01/19 12:14:04 2038/01/19 12:14:05 2038/01/19 12:14:06 2038/01/19 12:14:07 1901/12/14 05:45:52 1901
2038年問題とUNIX時間
コンピュータにおける2038年問題をご存知でしょうか？ ちょうど猫さんと鰹くんがコンピュータの日付や時刻に関してお話しているようなので、ちょっと会話を覗いてみましょう。 ： 鰹「最近ね、2038年01月19日の日付のスパムメールがよく届くんだけど、どうしてそんな未来のメールが届くの？」 猫「それはね、メールの送信日付（Date:フィールド）をメールの送信者が付けることになっているのを悪用して、スパムメールが常に最新のメールとして上位に表示されるように、故意に未来の値にしているんだね」 鰹「でもなんで、2038年01月19日なんてキリの悪い日付なの？2100年とか3000年の方がキリが良いじゃない」 あれ、鰹くんのいっていることって何処かおかしいですね。 鰹くんと猫さんがお話を続けているようなので、もう少し見てみましょうか。 猫「そうだね。動物の世界では2038年よりも3000年の方がキリが
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
ANSI Cなど標準的なC言語の仕様では、プログラム上で日時を処理するのに、世界標準時1970年1月1日0時0分0秒(EPOCH TIME；日本時間では同日9時0分0秒)からの経過秒数（エポック秒）を使っている（ちなみにこれはUNIXの仕様に由来する）。 この数値を扱うデータ型「time_t型」は「符号付き32bit整数(signed long int)型」として確保しているシステムが多いため、符号部を抜いた31bitで表現できる最大の数値である2147483647秒(日時に換算すると2038年1月19日3時14分8秒)を超えると桁あふれを起こしてしまい、時刻の判定に誤動作を起こす可能性がある。 この問題は一般的なC言語のほか、同じエポック秒を利用し、これを扱うデータ型が符号付き32bit整数である他のプログラミング言語で作られたプログラムでも発生しうる。 対処法としては「time_t型」
OpenBSD 5.5がリリースされました。今回のリリースでの大きな変更点は、「2038年問題への対応」となっています（SourceForge.JP Magazine）。 # /.j には逃げ切れる方もいらっしゃると推察しますが… 2038年問題とは、1970年1月1日午前0時0分0秒（UTC）を起点としたUNIX timeが、2038年1月19日3時14分7秒で32ビットで表せる上限を超えてしまうという問題。OpenBSDではUNIX timeを扱う型（time_t）を64ビット化することでこの問題を解決している。
Linuxカーネル5.10ではXFSファイルシステムの2038年問題(Y2038)への対応が行われるようだ(Phoronixの記事、 The Registerの記事、 Darrick J. Wong氏のメーリングリスト投稿)。 Y2038は2038年1月19日3時14分7秒(UTC)以降、UNIX時間が符号付き32ビット整数で表現できる範囲を超えてしまうという問題だ。Linuxの場合、64ビットシステムでは64ビット整数が標準のためY2038の影響は小さく、32ビットシステムでもLinuxカーネル5.6でY2038に対応しているが、タイムスタンプに符号付き32ビット整数を使用するファイルシステムのY2038は32ビットシステム・64ビットシステムの両方が影響を受ける。 Linuxカーネル5.10のXFSファイルシステムではinodeのタイムスタンプとクオータ有効期限のタイプスタンプのデータ
「西暦2038年問題」でトラブル相次ぐ
図2●KDDIのシステムでは1月10日を境に、料金算出に使う時刻が過去の日時になった KDDIのシステムは0.5秒単位で経過時間を取得しているため、1970年と2038年の真ん中に当たる1月10日に桁あふれを起こした 今年1月10日は、UNIXの内部時間がスタートする1970年1月1日と、コンピュータの「西暦2038年問題」が起こる2038年1月19日のちょうど中間の日付に当たる（図1[拡大表示]）。1月10日には、KDDIなどさまざまな企業で西暦2038年問題に起因するプログラムの不具合や、その“亜種”とも言うべきトラブルが続発した。表にあるように、不具合が判明した事例だけで六つある。 西暦2038年問題とは、UNIX環境などで協定世界時（UTC）の2038年1月19日3時14分8秒を過ぎると、システムが正しく時刻を認識できなくなることを指す。2038年1月19日になって、1970年1月
B-CASカード「2038年問題」のとばっちりか？ : Computer with Audio/Visual
今週末、２ｃｈを中心に一部で祭りとなったT社製B-CASカードのセキュリティホール問題であるが、思わぬとばっちりを被った。 解決済み、「【続報】 B-CASカード「2038年問題」のとばっちりか？」の記事を参照されたし（5/19追記） http://blog.livedoor.jp/mtatsu0206/archives/52270240.html 契約しているにも係わらず、上記メッセージが出力されるようになった。 但し、Blu-rayレコーダに当B-CASカードを入れると出力されない。 またPCに戻すと出力されるようになるのだ。 但し、TSSplitterで余分なストリームをカットしてやることで回避可能である。 上記の様に影響を受けない。 但し、録画しつつ視聴する場合には、そういう訳にいかない。 昨日までは、この様なことは無かったので、e2でなんらかの対応があったのかもしれない。 WOW
2014.04.01 デジタル（PC・スマホ） コンピュータの2038年問題による誤作動で核兵器が発射される！？ はコメントを受け付けていません 今、わたしたちの生活はコンピュータによって支えられています。 あらゆる情報が「0と1」のデジタルによって管理されているのです。 いわゆる「時刻」もその一つですが、実はこれが大きな問題を抱えています。 かつてあった2000年問題を覚えていますでしょうか？ 「Y2K」とも呼ばれ、当時は広く話題になりましたが、2038年問題はそれ以上に大きな爆弾として、非常にゆっくりではありますが確実に近づいています。 2038年問題の原因について、理解を深めておきませんか？ スポンサーリンク なぜ半端な年に起こるのか？ 今現在、世界中のコンピュータでは、さまざまなプログラムが動作しています。プログラムを作成する場合「プログラム言語」が必要になるのですが、とりわけ「C
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「2038年問題」が2000年問題と比べ桁違いにヤバい…社会インフラで障害も
Linuxカーネルを2038年問題に対応させるには
Big Sky :: 何もソースコードを変更せずに2038年問題を解決する。
サマータイムとうるう秒と2038年問題
2038年問題を再発させるコードが多数の場所にコピーされてしまっている
Linuxカーネル5.6、32ビット版で2038年問題への対応が行われる | スラド Linux
Ubuntuにおける2038年問題との戦い・暗号化設定の調整、SmartNICとUbuntu | gihyo.jp
2038年問題に対応した「OpenBSD 5.5」リリース | OSDN Magazine
XFSの2038年問題にオンラインでも勝利したい - Gentoo metalog
Debian、32ビットの「2038年問題」に対応へ | gihyo.jp
【スクープ】コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす
2038年問題でクッキーの有効期限がブラウザを閉じるまでになっていた | Sun Limited Mt.
TimeとDateTimeと2038年問題 - こせきの技術日記
第27回 32ビット環境に迫る「2038年問題」 検証で分かった事実
第25回 32ビット環境に迫る「2038年問題」 時計がおかしくなると……
「2038年問題」を華麗に解決！～エンジニアの仕事～｜Zenken株式会社 公式ブログ
第26回 32ビット環境に迫る「2038年問題」 検証における5つの疑問
2038年問題まであと8億秒 | スラド
2019年5月7日 Linux 5.1がリリース、新しい非同期I/Oインタフェース、2038年問題対策など | gihyo.jp
MySQLのtimestamp型に起きる2038年問題
2038年問題とは コンピュータの人気・最新記事を集めました - はてな
OpenBSD 5.5、2038年問題に対応 | スラド オープンソース
Linuxカーネル5.10、XFSファイルシステムの2038年問題に対処 | スラド Linux
コンピュータの2038年問題による誤作動で核兵器が発射される！？