Page 3 of 3
What is amazing is that even after all this work we can still make a mess of working with dates. All you need to do is to try and tackle a problem that involves a time that takes you past midnight to see what I’m getting at!
If you think that the millennium bug, when we all thought that the computer world would come to an end when the year date rolled over, was the last date crisis then you need to think again.
This particular problem was caused by many programs, not expected to last to the turn of the century, simply not storing the century part of the date and was entirely obvious and easy to avoid. There are much more subtle ways of making a mess of dates and times that are just as serious and much more difficult to fix.
By the way, the next big date bug is expected in 2038 when the Unix 32 bit time stamp rolls over to 0. Given that the Unix time and date system works by simply counting the seconds since the 1st of January 1970 using a 32 bit integer there is a most future date. The largest positive 32-bit integer represents a date of Tuesday 19th of January 2038 - and after this time all Unix time stamps will roll over and look like dates back in 1901.
A Unix date/time is a signed 32-bit number, so you can use negative seconds, which give dates and time before 1970. Using the largest 32-bit negative number gives a date of Friday 13th in December 1901 as the earliest Unix date. So if you try to book something in 2038 be prepared for it to happen in 1901.
Azure Outage - Date Arithmetic Details
Leap Year Gotcha for Azure