News First overflow error of 2022?!

[igor_kavinski]

YYMMDDHHMM just overflowed a signed 32 bit int

Happy New Year, indeed

 

[VirtualLarry]

That's not how time_t is stored on *nix.

 

[mxnerd]

Yeah. However, at least MS Exchange itself is working, it's the Ant-Malware part that was causing problem. Just wait for MS to fix it.

YYMMDDhhmm 2201010003 in string format converted to numeric format is greater than the maximum signed 32 bit value 2^31-1 = 2147483647 , so that definitely overflows.

How can any programmer still use 2 digits to represent year since year 2000 millennium bug?

 

[Ken g6]

That is a very weird format. As a string it works, but as an integer it's equally as difficult, operations-wise, extracting data from that as it is from a *nix timestamp. Or 1/60th of a *nix timestamp, which would match the accuracy there and would last far past 2038.

I assume it was done by a programmer desperate to save space, but not smart enough to know how to parse a *nix timestamp. Or perhaps too lazy to use a function when printing or logging the timestamp.

 

[Ken g6]

So, Ars Technica finally explained it. It was a version number!

Apparently, Exchange Anti-malware has a version number. Microsoft decided to set that to the date and time the version was created. Someone also decided it should be a 32-bit integer. Maybe a case where the left hand didn't know what the right hand was doing. Separate engineers making initially reasonable decisions, then trying to hack together a consensus - badly.