System timeGmt2005 overflows to LargeInteger on 1/5/2022
On January 5, 2022, the number of seconds since January 1, 2005 will exceed the value of SmallInteger maximumValue. At this time, the method System class>>timeGmt2005 will begin returning instances of LargePositiveInteger.
If your application uses the result of timeGmt2005 to assign to an instvar or element that is constrained to SmallInteger, it will trigger a constraint violation exception.
Since SmallIntegers are specials (where the oop directly encodes the numeric value), while LargePositiveIntegers are full objects assigned to an oop, the change to LargePositiveIntegers will use up OOPs within your repository, as well as extent space. There are also performance costs in performing arithmetic on LargePositiveIntegers vs. SmallIntegers.
Workaround
Before January 2022, it is critical that customers examine their application/s for uses of timeGmt2005, and determine the impact on the application. Upgrading to 6.7.2 or later before this changeover is strongly recommended.
The GemStone 6.7.2 release includes fixes for the similar issue impacting RcQueues (see bugnote for 46377.
The 6.7.2 release also includes the new method System class >> timeGmt2020, which provides the seconds since January 1, 2020, in seconds. It will return a SmallInteger until January 4, 2037.
Note that GemStone/S 64 Bit has a much larger SmallInteger range and is not subject to similar issues; converting to GemStone/S 64 Bit is strongly recommended for all 32-bit GemStone/S applications.
Last updated: 8/18/21