Why is anyone using two-digit years anywhere at all? This approach has already caused a lot of trouble 22 years ago. Do people learn nothing from their past mistakes?
I kinda feel you've never worked with a large code base or database that has a legacy going back 25+ years...older than many of the commentators on this thread.
Not all of the data types used might have been obvious in their "danger", especially in ancient code. Sure you could run some analysis over the code, but can that analyser determine from a #def or variable name the true intent of the value being stored?
I wrote an application for a customer in 1986, and stone me, they were still running it in a DOSBOX emulator in 2004. Lucky for me dates weren't important.
Famous last words.
The problem with fixing it, is nobody thinks it will be their problem.
DNS serial numbers are 32 bit unsigned and the convention is to use YYYYMMDDNN
So this _convention_ breaks in year 4295, or if someone forgot to put unsigned 2148. It is only a convention though DNS only cares that the serial increases.
Because with four-digit years this kind of date would never have fit into a signed 32-bit integer. Incidentally, this shows that the timestamp was taken into use after Y2K, since none of the pre-millennium years would have fit.
But.. they wouldn't be able to use int32 and therefore wouldn't have had this bug. :)
If you are making a calendar app, you want to store dates and not timestamps as, e.g. if I have a flight to another country then have an appointment at 9am, that 9am should be in the time zone of wherever I am physically present, which the calendar doesn't necessarily know.
Storing as an integer is compact and allows for easy comparison. It's a clever hack, but they should have used 64 bit, or at least a u32!
In 99% of the cases you only really want to involve timezones when presenting something to the user or taking input from them.
So you would create your calendar event by entering "9am, timezone X", and the app would most probably just apply that offset and store that as a timestamp. But if it's an all-day event... I should probably take a look at android's calendar content provider.
Referring to something like "Christmas day" as timezoneless doesn't help either. Anyone who celebrates it celebrates it in a timezone. Christmas Day EST is a different event than Christmas Day CEST. Trying to represent them as the same event will only lead to heartbreak.
Generally I think Dates (without time) are usually considered time-less and therefore timezone-less.
In fact the examples you mention are only a concern when considering the start or end of Christmas Day, and not the actual date of Christmas Day.