The 19th January 2038 is 2^31 seconds after the unix epoch, when 32 bit linux timestamps wrap around. On 16-bit PIC microcontrollers the default implementation of the gmtime function wraps already 0x0x7C55817F seconds after the unix epoch (I forgot why, it was probably about efficiency). That works out to 7th February 2036, likely catching a lot of companies off guard (seemingly everyone focuses on 2038). Some systems also use 1980 as the epoch, so maybe we'll see some problems again in 2048.

Calling it just the Year 2038 problem is misleading because lots of platforms and implementations add their own twist, skewing the crucial date by a few years. Linux is a big platform, but there are countless niche alternatives as processor resources get scarce or realtime requirements get tight.

2036-02-07 06:28:16 UTC is 2^32 seconds after 1900-01-01 00:00:00 UTC. Some systems represent time using a 32-bit unsigned integer counting seconds since 1900.

1 JAN 1970 was a judicious choice for the UNIX epoch date; it allowed a 32-bit signed integer time_t type (counting seconds) to handle dates almost all the way back to the year 1900 as well as 'way into the future.