Yes, there are random systems using every kind of smart or brain-dead option out there.

But the 2038 problem impacts the previous standard, and the current one will take ages to fail. (No, it's not 33000, unless you are using some variant of the standard that counts nanoseconds instead of seconds. Those usually have more bits nowadays, but some odd older systems do it on the same 64 bits from the standard.)

I'm pretty certain most of my work inevitably ends up being related to a time issue

Just start over at year 0000 AT (after ten thousand)

The ISO time standard will certainly need to be redone

33,000 would come from other programs that store the year as a 16-bit signed int. Year 32,768, to be precise.

A common method of storing dates is the number of seconds since midnight on Jan 1, 1970 (which was somewhat arbitrarily chosen).

A 32-bit signed integer means it can store numbers between 2^31^ through 2^31^ - 1 (subtracting one comes from zero being effectively a positive number for these purposes). 2^31^ - 1 seconds added to Jan 1, 1970 gets you to Jan 19, 2038.

The solution is to jump to 64-bit integers, but as with Y2K, there's a lot of old systems that need to be updated to 64-bit integers (and no, they don't necessarily have to have 64-bit CPUs to make that work). For the most part, this has been done already. That would put the date out to 292,277,026,596 CE. Which is orders of magnitude past the time for the sun to turn into a red giant.

Unix computers store time in seconds that have passed since january first 1970. one there have been too many seconds since 1970, it starts breaking. 'signed' is a way to store negative numbers in binary. the basics of it are: when the leftmost bit is a 1, it's a negative number (and then you do some other things to the rest of the number so that it acts like a negative number) so when there have been 09999999 seconds since 1970, if there's one more second it'll be 10000000, which a computer sees as -9999999.