Pro tip: never try to convert the date (formatted as "yyMMddHHmm") in an int32.
It will stop working in 2022. 😉

I just found out I accidentally invented the "2022 bug" two years ago.

Microsoft can claim prior art on that one.

What possible reason would you have to do that anyways?

Why not just encode seconds (even milliseconds) since before the big bang in an int64?

The reason was very stupid, and the solution to the initial problem that caused the error even more.
We generate a record ID based on different selections made by the user plus the date and time ("yyMMddHHmm"). Which is far from perfect from the beginning but I'm not the one that invented it and the software is 20 years old and widely used, so it's too late to change everything.

It was reported that some clients were able to input the same data more than once under 1 minute, so the generated IDs were duplicates causing error messages and forcing the user to input the data again and have to wait more than 1 minute every time. It's a very stupid case which nobody expected (that function shouldn't be used so much with the same data but somehow somebody managed to do it).
A really fast solution was to convert that part of the string to int and increment it in a loop until an unique ID is available (the other parts of the string can't be changed). I never counted the digits to realize it's exactly 10, and that the 1st January 2022 converted is greater than 2.147.483.647, the int32 limit (in fact is 2.201.010.000, 31st December 2021 is 2.112.310.000, so the issue has been found only now).

@Demolishun I personally always use mouse heartbeats (MHB) since the previous full moon, then full moons since the last winter solstice point of an El Niño warm phase of the southern oscillation of the oceans, then the number of El Niños since the last perihelion of the Kobayashi Comet, starting at its closest point to the sun in 1972.

So it's currently 2 Kobayashi, 7 El Niño, 38 Moon, 13088725 MHB.

I'm pretty excited about this year, because Kobayashi will return in only 4 moons and 24012000 MHBs, right after a full eclipse!

Super convenient, once you get used to it...

Also, you don't need to carry a watch anymore, I just look up at the sky at night, use my finger to feel the moisture levels of the jetstream between the tropopause and the Ferrel cell, and then of course I check my atomic pocket mouse which has been carefully calibrated to 575bpm.

@bittersweet Just as long as you store in int64 I am good.

@Demolishun Well when I store it digitally I convert it to thousands of each rotation of Hessel's pulsar, which is 100M years old and pulses 716.3555 times per second...

So sadly I'm 3 bits short when using int64.

@bittersweet You might be a few bits short, but it isn't the int64 that is short those bits.

@Demolishun 😂

@JS96 any id with meaning is stupid. Causes side effects and even dumber hacks using it.
1. you should have just created a new id along side (no longer guarantee uniqueness and deprecate the crappy one)
2. Could have done the same trick with just parsing the date/time and increase that. Benefit is that it remains a valid time (and not get 61+ min) even though it lies about the time anyway and may break stuff that is not future proof.

@hjk101 I totally agree, the whole system was poorly made unfortunately. It's something I would never even thought about.
Anyway, the date and time part was only to generate "unique" IDs, but it failed, so having 61+ minutes is not an issue in this particular case.