# Y2K22 issue with build number

**URL:** <https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701>\
**Category:** Module Development\
**Created:** [January 5, 2022, 8:45pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701 "2022-01-05T20:45:51Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![james.vosler](https://avatars.discourse-cdn.com/v4/letter/j/8797f3/32.png) [@james.vosler](https://forum.inductiveautomation.com/u/james.vosler)\
**Post date:** [January 5, 2022, 8:45pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/1 "2022-01-05T20:45:52Z")

</div>

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

> \<maven.build.timestamp.format\>yyMMddHHmm\</maven.build.timestamp.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:

> \<maven.build.timestamp.format\>MM **yy** ddHHmm\</maven.build.timestamp.format\>

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:

> \<maven.build.timestamp.format\>yy **ddd** HHmm\</maven.build.timestamp.format\>

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 5, 2022, 10:00pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/2 "2022-01-05T22:00:01Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [January 5, 2022, 10:07pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/3 "2022-01-05T22:07:08Z")

</div>

I thought the next Y2K wasn’t until 2038?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 5, 2022, 10:09pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/4 "2022-01-05T22:09:47Z")

</div>

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** _.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [January 5, 2022, 10:17pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/5 "2022-01-05T22:17:25Z")

</div>

If it’s good enough for [Microsoft](https://www.onmsft.com/news/fix-for-microsoft-exchange-bug-now-available), it’s good enough for us 🙂

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

---

<div class="post-metadata">

**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\
**Post date:** [January 6, 2022, 7:32am UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/6 "2022-01-06T07:32:32Z")

</div>

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…

```auto
<maven.build.timestamp.format>yyyyMMddHH</maven.build.timestamp.format>

```

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/6/d6c765cb6ba9f11b82c3f9f8cc3d84682f3d0243.png)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 6, 2022, 1:43pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/7 "2022-01-06T13:43:55Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![james.vosler](https://avatars.discourse-cdn.com/v4/letter/j/8797f3/32.png) [@james.vosler](https://forum.inductiveautomation.com/u/james.vosler)\
**Post date:** [March 2, 2022, 1:53pm UTC](https://forum.inductiveautomation.com/t/y2k22-issue-with-build-number/54701/8 "2022-03-02T13:53:52Z")

</div>

Correction: According to [Maven – Introduction to the POM](https://maven.apache.org/guides/introduction/introduction-to-the-pom.html), the date format follows [https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html](https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html), which requires capital D for the julian date:

> \<maven.build.timestamp.format\>yyDDDHHmm\</maven.build.timestamp.format\>