The Year 2038 problem relates to representing time in many digital systems as number of seconds passed since 1 January 1970 and storing it as a signed 32-bit binary integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. Just like the Y2K problem, the Year 2038 problem is caused by insufficient capacity of the chosen storage unit
The latest time that can be represented in Unix's signed 32-bit integer time format is 03:14:07 UTC on Tuesday, 19 January 2038 (231-1 = 2,147,483,647 seconds after 1 January 1970). Times beyond that will wrap around and be stored internally as a negative number, which these systems will interpret as having occurred on 13 December 1901 rather than 19 January 2038. This is caused by integer overflow. The counter runs out of usable digit bits, flips the sign bit instead, and reports a maximally negative number (continuing to count up, toward zero). Resulting erroneous calculations on such systems are likely to cause problems for users and other relying parties.
Programs that work with future dates will begin to run into problems sooner; for example a program that works with dates 20 years in the future should have been fixed no later than 19 January 2018.
I don't have to worry about this because I wouldn't around to live long enough to see.