![]() The problem, of course, is that in a leap year, there will not be a place in the array for the 366th day, December 31st. The key point is that we're declaring a fixed-size array to hold data, and assuming that there will be a location in the array for every day of the year. The above C code could just as easily be rewritten in C# or another language, or use a string or some other data type instead of an integer. #2: Declaring an array of values for each day of the year int items Your application may be expecting February 28th, and if so it will need to adjust. The key difference though is that instead of it failing, when passing February 29th in a non-leap year, it will produce a value that represents March 1st. Instead of SystemTimeToFileTime, you might call _mkgmtime to produce a time_t structure. Months are 0-11 instead of 1-12, so Februrary is month 1. The tm struct is used instead of SYSTEMTIME, which has slightly different behavior. Note that a similar bug can also occur in standard C++ (non-Windows) code as well. St.wDay = st.wMonth = 2 & st.wDay = 29 & !leap ? 28 : st.wDay If it's Feb 29th, but it's not a leap year, then move back to Feb 28th SYSTEMTIME st // declare a SYSTEMTIME variableīool leap = st.wYear % 4 = 0 & (st.wYear % 100 != 0 || st.wYear % 400 = 0) Correctly add a year to a SYSTEMTIME by checking the validity of the result and adjusting when necessary:.Always check the status result of Win32 functions, especially SystemTimeToFileTime.This can lead to unpredictable results, such as leaving a FILETIME value in its uninitialized state. Unfortunately, it is extremely common to find code that uses this method without checking the return value. This value might be passed around quite a bit before it ultimately ends up as a parameter to another function, such as SystemTimeToFileTime, where it will cause the function to fail with a return value of zero. For example, + 1 year =, which does not exist! ![]() However, the risk is that if the code is called on February 29th, the resulting value will still be on February 29th, but in a non-leap year. GetSystemTime(&st) // set it to the current date and time It is very common to see the following code: SYSTEMTIME st // declare a SYSTEMTIME variable It has distinct fields for each part of a date, separating the year, month, day values (and others). In C / C++ code that uses the Win32 API, the SYSTEMTIME structure is a common representation of civil time. The two most dangerous leap year bugs #1: Adding or subtracting years in C / C++ I'm sure thousands more occurred with varying degrees of impact and noticeability. These are just the big ones that made the news. Lotus 1-2-3's miscalculation of year 1900, which still impacts Microsoft Excel today, over 30 years later!. The 2008 Microsoft Exchange management bug, which prevented administrators from doing much of anything on February 29th. The 2010 Sony PlayStation Network outage - caused by misidentification of 2010 as a leap year The 2008 bricking of all Microsoft Zune devices - caused by a logic error on December 31st. Past leap years have included some high-impact, high-profile bugs, such as: The 2012 Microsoft Azure outage - where miscalculation of a certificate expiration date caused service disruptions for up to 12 hours. ![]() ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |