I actually have written code like this to deal with the Y2038 problem UNIX will have (for UNIX systems that still use a 32-bit time_t on January 19 2038, they will roll over and think they are in 1901) by seeing if time_t is 32-bit (my code uses 64-bit numbers for timestamps). If so, it will assume we're past 2038 and not before 2007 if time_t is a time before 2007. This moves the Y2038 problem to 2143, at which point hopefully there will no longer exist anything which uses a 32-bit time_t.

One bug caused by this is that embedded software developers sometimes started my daemon before setting the system time, which caused issues because my code thought the year was 2106 (and not 1970). My answer was to tell the guy to always set the time before starting my daemon. I could also make the death date 2106 (instead of 2143) to stop developers from doing that, but I'm not getting paid enough to protect people making money from my volunteer work from their own stupidity, and adding 37 years before it stops working makes it that much more likely anything and everything using that code will be gone before there are issues.