How about rewrite that piece of code and set the start date at Jan 1 2015?
That'll screw up all dates that are stored as a 32-bit integer. I suspect this includes FFS.
I need to dig out an A500 without critical files on it and set the date to beyond its limit and see what happens to system time, file stamps, the RTC, etc. What happens when rebooted?
I think the RTC will be OK until 1 Jan 2078, but SetClock won't understand the date and will probably fail with invalid data, or will overflow and set some obvious incorrect time.
There's no easy solution to this,
all the instances where a 32-bit timestamp is stored will need to be changed, and
all software which uses timer.device directly will need to be adapted to use a 64-bit value. Everything using the old 32-bit API will break with dates after 2036. I don't think there is any way to workaround this problem other than assuming the overflow has happened, and then you're breaking dates before 2036 which isn't necessarily an improvement.
I suppose you could say "high bit set means before 2036, high bit not set means after 2036", but you're still breaking dates before 2007, and only delaying the problem for another 29 years.
