Left as an exercise for the reader
Devise "a string compare function that interpreted 2010 as being earlier than 2009", given the additional constraint that it presumably must also give 2008 < 2009 and 2009 = 2009. (The latter constraint precludes simply returning a random result, which must by now be what Symantec's customers believe was happening.)
Oh, wait, I've just figured it out. They're reading the dates from right to left, so we have ...
0102 < 9002
8002 < 9002
etc
...so if Symantec's customers just sit out the next decade, they'll be fine come 1 Jan 2019. OK I'm kidding, but you have a go. Just *how* can you write a string comparison with the behaviour claimed by Symantec?
A far more likely explanation is that the bug gets all year comparisons wrong, or simply ignores years, but was written within the last 12 months and released without even the most elementary "new year" testing. As a result, the bug is seen for the first time on customer systems on a day when all the developers are on holiday.