ワォー！急遽、出勤する人いるのかな。

うえぇ、なんだその実装。

年始早々、、、

「2022年の日付の最小値は2,201,010,001以上で最大値を超えるため」<あれ?今年って1970年と2038年の折り返し地点?いや違うよな…?などと思いを馳せた後、文字列化した日付を整数で表現していることに気付いた。何その仕様…

今見たら記事の方は直ってました。
署名付きint32 -> 符号付きint32

以降の日付が問題になる、と。んなアホな。いつごろ追加されたコードなんだろうか。

これイマイチピンと来ないんだけど、5個の10進数二桁の数値に6ビットずつ割り当てて(2ビット捨てて)使ってたって事なのかな？

うわぁ、マジか・・・。

PC開くのこわい＼(^o^)／

＞2022年の日付の最小値は2,201,010,001以上で最大値を超えるため

そういう日付の入れ方するの！？…とかバカにしている人多そうだけど、絶対に他にもありそうだよなぁ(^^;)

年明け出社したら地獄が待ってそうだなぁ（遠い目

オーノーだずら＞

まさかの2022年問題
設計者はint32が無限とでも思ったのか

酷いやらかしでワロタ
2,201,010,001ってなに？ってなったが、
コメント見て理解したｗ
10進で格納ｗ高速化のつもりでビット演算？ｗ
ダメ仕様だなｗで大問題ｗ

どこかやるだろうと思っていたらMSがやらかしました。
MSもイマイチ型を理解していません。

20世紀ぽいな… (;ﾟロﾟ)

これか(うちの管理してるところは影響なさそうやけど…お客さんとこどうなんやろね。

吹いた。
2201/01/01=2,201,010,001が符号付き32bit変数を超えたのか

signed int（署名付き整数）ってこれが元ネタか -

正月返上で仕事してるのにやけに静かだなぁと思ったら 年明けにメール来ないって言う人たくさんいそうだなコレ。

"signed"を「署名付き」と訳しちゃったか。itmediaなのに？

これと同じint32問題をやらかしたような気がする。

00時00分をintで2201010000にするって酷い仕様だな…あり得ないわ…

ザワついてる…

【メモ】
▼ by 🇯🇵

【元ネタ英文記事】
▼Microsoft Exchange Y2K22 bug in FIP-FS breaks email delivery
by 🇺🇸
※符号付整数オーバーフロー

1世紀前にも色々あった形式。
↓
Microsoftが符号付きのint32を使った日付の値の最大値を2,147,483,647にしている事が原因。
2022年の日付の最小値は2,201,010,001以上の為、スキャンエンジンがクラッシュする。
↓
Exchange Server、日付チェック問題でメール配信停止

どんだけ古い製品かと思ったら全然そんなことなかったね

ひどいな、これ。

int32って
>

マイクロソフト大丈夫かこれ

あぁ、アカン間違いだけどIT従事者でもなければわからんよね。
C言語を勉強したことがある人ならわかるかもだけど
unsigned はデータ型の接頭辞なんだよね。

符号付きとか符号なしとか論理回路の勉強したことがある人もひょうっとすると聞いたことがあるかもなぁ。

22年1月1日＋0001 をそのまま数字としてつなげた 2,201,010,001 を 32bit 整数に入れたら 2の31乗 (2,147,483,648) を超えて日付がマイナスになったって、MS なんちゅーバカコード書いとんの

”Microsoftが署名付きのint32”

ITについてのメディアがこの訳し方はどうなんだろう。

：

signed int32を署名付きと訳してるのはIT系メディアとしてはあまりにもお粗末（正しくは符号付）

さらに、signed int32型の変数が表現できる上限2147483647を越えたことが原因という説明の訳も

（日本語の記事出てました・・）

「署名付きのint32」今、この誤訳の方が話題に！

そう言う実装なのかー（しろめ

署名付きのint32 🤣

えぇ(;´д｀)
Exchange鯖だけだよね？？？
365は関係ないよね？ ね？？？

問題はこれか！

またまぁ正月早々に大変だ…(ヽ'ω`)

新年早々大変だねー
うちはEX Onlineでオンプレは残存するだけで使ってないはず ですか？w

2036と2038年、昭和100年問題にはまだ早いと思ったけど、そんな方法があったかー(白目

日経ならともかく IT Media を名乗ってるとこが signed int32 を"署名付きのint32"と翻訳するのはちょっとレベルがアレすぎるんじゃないですかねぇ……

『Microsoftが署名付きのint32を使った』
signed intを署名付きのintって訳している人初めて見た

「署名付きのint32」使いテー

そもそも、マイナスが必要無いのに、なんで signed。

取り敢えず動くという実装は危険。
記事がイマイチなので補足すると、yymmddhhmmでint化する仕様で、uint32の最大値2147483648を超えてエラーになってるそうだ。2022年1月2日 3:04であれば2201020304という感じ。

出たよ新年早々アホみたいなバグが ホントこの企業の体質は長年変わらん |

ひゃーこんな2022年問題もあるのか。

お、おう。＞ 『Microsoftが署名付き（誤訳で正しくは「符号付き」）のint32を使った日付の値の最大値を2,147,483,647にしていることが原因という。2022年の日付の最小値は2,201,010,001以上で最大値を超えるため、スキャンエンジンがクラッシュし、メールをスタックさせる』

「日付文字列生成にint32を使うような（どアホな）実装」の話なんだけど、この記事だけ読んだら「MSが署名付き int32の最大値を引き上げたら解決」みたいに認識する人が出るんじゃなかろうか。

署名付きのint32って、訳してて疑問に思わなかったのかな。

なんで2000年以降に作ったとおぼしき部品でそんな実装しとんねん(この実装だと1999年以前でも同じバグが起こるはず)

「signed int32」を「署名付きのint32」と翻訳してて草生えるwww
正しくは「符号付きのint32」です。

こんな2022年問題があったのか。

2022年問題なんてあったんか・・・w

「署名付きのint32」って間違いがあので、翻訳記事っぽいけど出典が書いてないな。自社記事の場合でも、翻訳記事の場合でも、知識があやしい人が書いてるしチェックも不十分だね＞

んんんん？w

えっ、Exchange2016と2019で起こるの？32bitのunsinged intをわざわざ使ってるの？いまの話！？

署名付きint32 -

signedはこの場合「署名」じゃなくて「符号付」ですね。それにしても2022年01月01日00時00分を2201010000と変換するセンス…誰もint32の幅に気づかなかったの？この調子じゃ2038年問題の地雷もあちこちに埋まってそう。

署名付きint32って signed int32 のこと？あれって署名付きっていうの？符号とかじゃないの？

教えてくれw知らないかもだけどww

つうか何なんこれwww

年始早々にナニやってくれてんのよ😰
しかも Exchange Server を社内運用している会社はパッチ当てるかワークアラウンド対応しない限りメールが停止するってコトでしょ？
うわー😭
年始早々の の苦難だなー...

「署名付きのint32を使った日付の値の最大値を2,147,483,647にして」正しくは「最大値が2,147,483,647である符号付きint32に日付の値を入れて」。ITmediaの中の人がintとか知らないのがよく伝わってくる。

あ～～あ～～、大変だ～ね～。

「署名付きのint32」を見て、セキュリティ関連はそんな型を使うのかと思ったけど、「符号付き」を知らない人が記事書いて、知らない人が校正してるね？ ＞

ﾋｴｯ｜

「31ビットで日付を表現していて，それを超えたので扱えなくなった」ということらしい．
それはそうとして，「signed int32」を「署名付きのint32」と訳した記事を書いたのは誰？

オンプレExchangeの方新年早々ご愁傷様です。。。

「Microsoftが署名付きのint32を使った日付の値の最大値を2,147,483,647にしていることが原因」
署名付きint32って何の事かと思ったらsigned intの事が。
クソ翻訳だ

日本語のニュースも出たか

テスト環境としてintが31bitの処理系を作ったら事前に判るんじゃないかな

2022年の日付の最小値は2,201,010,001以上で(intの)最大値を超える＞
MS「2038年問題先取りゲットだぜ！！

このまま3ヶ月くらい止まり続けてくれればいいのに >

Microsoft Exange serverみたいですねー。

正月から大変やな(ﾊﾅﾎｼﾞ

2000年問題よりー自分の夢ー

はひ？

「署名付きのint32」って、仮にもITを名乗るメディアでそれはないだろ…。signed intだろ…。

日付時間文字列（しかも西暦は2桁！！）をそのままInt32にぶち込むなどというセンスの無さな…昔の計算リソース節約術じゃないんだからさ。

古い組織ほど死んでそうな不具合で草です

> 署名付きのint32
Signed……

新年から話題を提供してくれます。「int32を使った日付の値の最大値を2,147,483,647にしていることが原因」

2000年問題のプチ版みたいなこと起こってんなぁ

古いアプリならともかく割と最近のバージョンなのにこれは稚拙過ぎないか -

んー、こんなニュースが

「Microsoftが署名付きのint32を使った日付の値の最大値を2,147,483,647にしていることが原因」 符号のsignedが署名に訳されているっぽい ／

また365に影響？

日付の値の最大値を2,147,483,647にしていることが原因という。2022年の日付の最小値は2,201,010,001以上で最大値を超えるため

これ西暦下2桁+月+日+時+分？
馬鹿なの？

面白バグ。基本的なコンピュータのしくみを理解していない素人がプログラムを書いている会社。ゲイツはちゃんとコードレビューしよう

ありゃ

『署名付きのint32を使った日付の値の最大値を2,147,483,647にしていることが原因/2022年の日付の最小値は2,201,010,001以上で最大値を超えるため、スキャンエンジンがクラッシュ』

うそだろ…_(:3 」∠)_

「Microsoftが署名付きのint32を使った日付の値の最大値を」って、これ「符号付きの」ですよねw

オンプレExchange運用しているエンジニアの年始初仕事が決まった感じ？
いや、業務開始前に対応しないとダメな奴？

＞Microsoftが署名付きのint32を使った日付の値の最大値を2,147,483,647にしていることが原因という。2022年の日付の最小値は2,201,010,001以上で最大値を超えるため、スキャンエンジンがクラッシュ

セキュリティ研究者のジョセフ・ローゼン氏によると、Microsoftが署名付きのint32を使った日付の値の最大値を2,147,483,647にしていることが原因という"

「署名付きのint32」

大きなバグになりそうか？

Int32のオーバーフロー?
先頭2桁が西暦の下2桁

21...→22... になって

新年そうそう辛いな。