As we enter February, it's a good time to remember that 2016 is a leap year. For most people, this may just be an interesting oddity; an extra day to work or play. But for software developers, the leap year can cause significant pain. If you are just now thinking about checking your code for leap year bugs, you better move quickly. In fact, you might already be experiencing the effects and may not even realize it! What kind of bugs might be lurking in your code? •Off-by-one issues, especially around data filtering using date-range queries •Unexpected or undesired behavior in user interfaces •Potential for exceptions, crashes, or hanging as edge cases are encountered “Meh,” you say. “My code is just fine. We have unit tests.” “Oh really,” I say. “Do your tests properly mock the clock? Do they test edge cases including February 29 and December 31? Have you tested any low-level C++ code you might have as well as the rest of your system? Do you even know what a leap year bug looks like?” Most often, blank stares. https://azure.microsoft.com/en-us/blog/is-your-code-ready-for-the-leap-year/
Back when I got my first copy of Turbo Pascal circa 1992 or 3 the first thing I did was write a routine for exactly that, figuring out leap years, which was incorporated into every other program I have written since. That was back when I was still running DOS 3.1 for an operating system.
In fact, you might already be experiencing the effects and may not even realize it! How? lol, we haven't reached the 29th yet
Easy ... if you have a program that needs to calculate the date several months from now - for example, a delivery date - and need to know the day of week (so for example, you don't land on a weekend) .... the date your calculating would be after the 29th.
Ponder the implication of the following... From : http://blogs.perl.org/users/ovid/2013/10/fighting-20-year-old-software-bugs.html
Basically it's just programmers making mistakes - if they had coded it correctly in the first place, a leap year wouldn't make any difference at all
Not so much mistakes, but oversights. Who really cares about leap years anyway when your boss ( ) is screaming over your shoulder for you to get the job done ?
Code: if(year % 4 == 0 || year % 400 == 0 || year % 100 == 0) cout << "this is a leap year" << endl; else cout << "this is not a leap year" << endl; Nope...I don't worry about it.
In Belgium there are the Belgacom/Proximus set top boxes that didn't record episodes they were programmed to record on the 29th. I don't own one of them though (I have Telenet as my provider), so I don't know how it exactly happened. But can it really be that hard? If you're using existing datetime libraries like the ones built on with almost every programming languages you should be pretty save I think. Don't try to reinvent the wheel, just use existing libs that proved to be working over time.
Here's an article about Zeller's Congruence. It's used to calculate the day of the week, given a date. It takes leap year into account, so, any date routines based on it are safe. https://en.wikipedia.org/wiki/Zeller's_congruence
I think that's when 2 digit years change century. Right now 38 - 99 means 1938 - 1999, 00 - 37 means 2000-2037. At some point this should change, because when it's 2040 we want 38 to be 2038 and not 1938 anymore.
The 2038 bug will only happen on systems that use UNIX Time. UNIX time is a 32-bit value that counts all of the seconds since January 1, 1970. Sometime in 2038, that 32-bit number will reach its maximum value.
Now I understand... Thanks for clarifying it sl1fka. http://stackoverflow.com/questions/471248/what-is-ultimately-a-time-t-typedef-to