The older ones among you will remember the much dreaded year 2000 bug => https://en.wikipedia.org/wiki/Year_2000_problem
Today I discovered that there is still plenty software around using 2-digit year entries and when those are evaluated relative to the current year, things are going to break.
Related: software that assumes that this will print 0
perl -e 'use Time::Local; print Time::Local::timelocal(localtime(0))'
will break in 2020, because localtime returns a year of 70 and timelocal will then interpret that as 2070.
There is certainly more than just this in the wild: https://github.com/dateutil/dateutil/pull/621 python-dateutil FTBFS-2027
perl-Test-MockTime FTBFS-2020 https://rt.cpan.org/Public/Bug/Display.html?id=124508
perl-TimeDate FTBFS-2020 https://rt.cpan.org/Public/Bug/Display.html?id=124509
perl-OLE-Storage_Lite FTBFS-2020 https://rt.cpan.org/Public/Bug/Display.html?id=124513
perl-Parse-Win32Registry breaks in 2020 https://rt.cpan.org/Public/Bug/Display.html?id=124514
perl-Archive-Zip breaks in 2030 https://rt.cpan.org/Public/Bug/Display.html?id=124512
and perl-Time-modules being more complicated
unrelated to this, there is also plenty software that breaks for other reasons in the future, because suddenly the previous future is the past.
https://bugzilla.opensuse.org/show_bug.cgi?id=1081871 mbedtls gpgme libvirt libressl python-M2Crypto python-trollius python-urllib3 python-vcrpy python-keystoneauth1 python-keystoneclient python-keystonemiddleware
luckily 90% of this only breaks the tests... but OTOH I only looked for (future) Factory build failures so far, so there will be more and worse... and 2020 is not so far away either.
Ciao Bernhard M.