Y2K is really weird for any number of reasons. The whole problem was that, supposedly, you'd assume that "years" stored in your application were added to 1900 and ranged from 0 to 99; then when adding the last year, 99 would roll over to 00 instead of 100... but it's extremely unlikely anyone would make a system that can work like that. It simply isn't an even remotely likely way that anyone would create that particular functionality - (although some might have). Even if they did, there's another problem:

While it's true that numbers do roll over their maximum value (so that "max + 1 == min"), there is no datatype that goes from 0 to 99. If the general concept held (ie. that you store years as some kind of 1900 + x value), you would store that 'x' in the form of a byte, most likely - and a byte ranges from 0 to 255, so the year wouldn't roll over until 2155. Then you'd have the Y2156 problem rather than the Y2K, and that's just not as catchy.

In addition to all that, it would simply be easier to store the year in a different, larger type. Hell, take two bytes, and you're suddenly able to specify ~32k years both BC and AD. Even taking into account a bunch of rather strange reasons people might have for "optimizing", you would have to both implement your date handling in such a weird way AND fuck up in a highly specific way, in order to eventually end up with Y2K problems - I can only really see that happening if you specifically try.