Martin Brown:

That works OK for mortgage intervals, but leaves you with an ambiguity
where absolute dates are concerned. In particular the lazy habit of
concatenating the string "19" in front of YY goes badly wrong when YY
becomes 100. USNO website scripts had this problem showing the rather
bizarre leap into the future "19100" instead of "2000".

LOL. But, if you don't add the "19", thing that I would avoid anyway,
pretending you have an information you don't is a real crime, everything
works fine.

Such things occurring in an embedded system where the destination buffer
is 4 bytes long can have very unpredictable results.

Sure The interface between the various parts of a system is the most
critical point.

Not true. It may be the only part of the problem that you understand,
but there were a whole raft of other things capable of going wrong.

Murphy rules!

Mostly to do with datestamps on historical data and making sure that
programs could cope with all the original data and the revised post Y2k
format as well. Stuff that was mission critical was done and tested in
good time, but they still kept key engineers dry and on standby for the
Y2k rollover. It was the fact that 2000 *is* a leap year whereas 1900 is
not that caused the most grief to bank customers when some banks got it
right and others did not. Japan took quite a hit on Y2k2.

http://news.bbc.co.uk/1/hi/world/asi...fic/660953.stm

I can't believe it! I learnt in school that every four years there is a
leap year unless it is the beginning of a century, but not a millennium.