Y2K22 issue with build number

We were using the build time stamp for our version number with the format:


and found that with the new year, the yy now overflows an internal toInt conversion, causing the module install to fail (Exception parsing module).

We attempted:


but found that the older version, with the higher build number, was archived in the gateway and was always being loaded in lieu of the the newer one. (Yes, we could have changed other portions of the version number). The jar files remained even when the module was removed. We had to shut down the gateway and manually delete them. Is there a better way to manage this?

We realized that the new format would regularly put us into this situation, so we now use the julian date instead of MM/dd to keep the build number shorter than the overflow size of integer:



Well, shoot. I’m going to have to do this too.


I thought the next Y2K wasn’t until 2038?

Print out the max signed 32-bit integer value, then compare digit-for-digit to the pattern above. ):

It would be nice if Ignition accepted a string.


If it’s good enough for Microsoft, it’s good enough for us :slight_smile:

I’ll check around to see if there’s something we can do here.


With the following format, used in IA modules, you don’t have any issue when loading modules in 2022, but the build version don’t have minutes…


1 Like

I very deliberately include minutes to accommodate quick fixes when troubleshooting. Not giving it up.


Correction: According to Maven – Introduction to the POM, the date format follows SimpleDateFormat (Java Platform SE 7 ), which requires capital D for the julian date:


1 Like