# Thread: hot to know if february has 28 or 29 days

1. ## hot to know if february has 28 or 29 days

Hi,

I would like to know how via javascript i can detect if a particular year has/had in february 28 or 29 days ?

thanks a lot,

M.

2. Code:
```var isLeapYear = function(year) {
var d = new Date();
d.setYear(year);
d.setMonth(1);
d.setDate(29);
return d.getDate() == 29;
}```

3. Originally Posted by kyberfabrikken
Code:
```var isLeapYear = function(year) {
var d = new Date();
d.setYear(year);
d.setMonth(1);
d.setDate(29);
return d.getDate() == 29;
}```
d.SetMonth(1) or d.setMonth(2), just asking ???

4. Why you r not using the leap year cndition that is

if( ((year&#37;4)=0) or ((year%100)!=0) and ((year%400)==0))

{
//its a 29 day
}
else
{
//28 day
}

5. Originally Posted by md_irfan_amu
d.SetMonth(1) or d.setMonth(2), just asking ???

As month names are usually processed from an array and arrays count from zero so do the month numbers. 0 is January and 11 is December.

6. Originally Posted by felgall
As month names are usually processed from an array and arrays count from zero so do the month numbers. 0 is January and 11 is December.
But then d.setDate() should use 28, otherwise it will be always wrong...

7. Code:
```function getMonthLength(iYear, iMonth) {
var iHour = 1000 * 60 * 60;
var iDay = iHour * 24;
var dThisMonth = new Date(iYear, iMonth, 1);
var dNextMonth = new Date(iYear, iMonth + 1, 1);
var iLength = Math.ceil((dNextMonth.getTime() - dThisMonth.getTime() - iHour)/iDay);

return iLength;
}

alert("February 2007 has " + getMonthLength(2007, 1) + " days");```

8. Yes, it's very useful, no need to check for leap years. This function was taken from the book "JavaScript Bible" written by Danny Goodman. Highly recommend it (new edition coming out next month).

9. Originally Posted by md_irfan_amu
Why you r not using the leap year cndition that is

if( ((year%4)=0) or ((year%100)!=0) and ((year%400)==0))

{
//its a 29 day
}
else
{
//28 day
}
That would have been my thought too. I don't know for sure but I suspect that the MOD operator (%) is faster than the date() methods.

10. Originally Posted by siteguru
That would have been my thought too. I don't know for sure but I suspect that the MOD operator (%) is faster than the date() methods.
That would be interesting to find out. Create a solution using % and lets compare!

11. Why you r not using the leap year cndition
I would use that way...

As month names are usually processed from an array and arrays count from zero so do the month numbers. 0 is January and 11 is December.
Yeah, it always confuse me.

But then d.setDate() should use 28, otherwise it will be always wrong...
But date is one-based.

12. There's more than one way to skin a cat:
Code:
```Date.prototype.isLeapYear = function() {
//make the first day of March 0 so you're at the last day of Feb
var tempDate = new Date(this.getFullYear(),2,0);
return (tempDate.getDate() === 29);
};

var testDate = new Date("5/1/2000");

13. Originally Posted by md_irfan_amu
But then d.setDate() should use 28, otherwise it will be always wrong...
setDate takes the actual date, whereas setMonth is zero-based. Confusing, yes.

Originally Posted by md_irfan_amu
Why you r not using the leap year cndition that
Because it's a bad habit to treat dates as primitives. It's a complex datatype. Your solution for example, calculates the wrong result for the year 1900, even if you correct the syntactical errors.

14. jtrefla: I don't think its a good idea to extend native JavaScript objects when you could easily create a function or a Utility class doing the same.

People start extending native objects too easily. Imagine the situation when your library of extended native objects meets 6 other developers having done the same...

15. And? Do you expect them to have different opinions on what a leap year is?

16. No, but it is just bad practice. Only extend native objects when you simply have to (maybe missing features in a JavaScript implementation, but I would still don't recommend it).

Maybe other developers think it it would be great to have String.prototype.convertToHTMLAndMakeEachLetterATab, Object.prototype.myVersionOfExtend or Number.prototype.makeNumberTenTimesBigger, that doesn't mean its a good idea for a production environment of 20 developers. All this, if necessary, could easily be achieved with a Utility class.

17. Originally Posted by Pepejeria
No, but it is just bad practice. Only extend native objects when you simply have to (maybe missing features in a JavaScript implementation, but I would still don't recommend it).
I'd have to disagree on this one. One of the things that makes libraries like JQuery and Prototype so great is that they make the native JavaScript objects *better*.

That's not to say that my implementation is better than using a utility class - I'm just saying that it makes more sense for a user to use the date object they've created to check if it's a leap year than to call a separate function:
Code:
```var someDate = new Date("1/1/2000");
if (is_leapyear(some_date)) {
//do stuff
}```
To me, it makes more sense to use the object I created:
Code:
```var someDate = newDate("1/1/2000");
if(someDate.isLeapYear()) {
//do stuff
}```
You can even chain it together:
Code:
```if(new Date("1/1/2000").isLeapYear()) {
//do stuff
}```
It just *feels* more pragmatic to extend Date() instead of creating a utility.

18. Actually, some of the JavaScript frameworks have been criticized for doing exactly that.

But, I am not here to change your opinion or say what is right and wrong. If you think its ok to extend native JavaScript objects, then fine. Just don't touch the Object object (since that would really break thinks).

You might question where the limit goes, if it's ok to extend native objects, is it also ok to overwrite methods as well? Maybe your "new" method does things better than the native one. But how will other developers know what has been changed? They shouldn't need to know what has been changed or added. They should rely on the existing implementation. Anyway, enough of rant.

You might wanna check out other opinions on this matter. But again, nothing is right or wrong.

19. Originally Posted by Pepejeria
Actually, some of the JavaScript frameworks have been criticized for doing exactly that.

But, I am not here to change your opinion or say what is right and wrong. If you think its ok to extend native JavaScript objects, then fine. Just don't touch the Object object (since that would really break thinks).

You might question where the limit goes, if it's ok to extend native objects, is it also ok to overwrite methods as well? Maybe your "new" method does things better than the native one. But how will other developers know what has been changed? They shouldn't need to know what has been changed or added. They should rely on the existing implementation. Anyway, enough of rant.

You might wanna check out other opinions on this matter. But again, nothing is right or wrong.
I've seen the work of Dean Edwards and it's great - I also agree with the first link's mantra of "Object.prototype" is off-limits.
I still fail to see the logic behind your justification of avoiding extending native objects. Even though Dean Edwards has designed base2 in a way to specifically avoid prototyping native objects, he still adds functionality to things (like the document object) that aren't (currently) part of JavaScript. For example, there is no document.matchSingle() method - but you get that when you use base2's base2-dom.js on your page. Regardless of how the document object suddenly has this method, how is that any different if "other developers" encounter your code? They are going to be just as confounded when they see document.matchSingle("form") as they are if they see dateObject.isLeapYear(), aren't they? Here's a quote from the page:
The bind() method fixes broken DOM methods and adds new methods like matchAll() and matchSingle() from the Selectors API.
(Granted, the Selectors API is technically drawn from the W3C, so it future-proofs the code): http://www.w3.org/TR/selectors-api/#documentselector
In this case, a future browser implementation of the DOM Level 3 matchSingle method may occur; but seeing it right now in somebody's code would be confusing just as well.

You might question where the limit goes, if it's ok to extend native objects, is it also ok to overwrite methods as well?
I would say that you shouldn't extend if you ever need to use for...in for that object. I don't recommend prototyping over existing methods...we are in agreement on that one

/rant

Whatever the case, using a utility function or extending the Date object will achieve the same result. The user will still have to include the code to do either one and one would hope that the code is documented well enough to ensure that future encounters by other developers will point them in the right direction.

20. Ummm...that post seemed like a flame - it's not; please imagine someone sitting in front of you with a smile on their face while baking you some cookies and reading that reply

21. Extending existing classes with the additional functionality required in your web page is a good way of making your code easier to read. Extending it with a whole lot of additional functionality that you are not using just bloats your page. That is why using prewritten libraries is not always a good idea as if there are 50 additional methods added by the library and you are only using one or two then your page is way bigger than it needs to be.

The setDate and setMonth methods for dates allow you to specify any number and if they are beyond the end of the month or year then the rest of the date will be updated accordingly. That's whay setting the date to the 29th February and then testing if the date is the 29th works because if February only has 28 days then setting it to the 29th makes the date 1st March.

22. Originally Posted by jtrelfa
Ummm...that post seemed like a flame - it's not; please imagine someone sitting in front of you with a smile on their face while baking you some cookies and reading that reply
That didn't seemed like a flame, on the contrary, it is always interesting to hear how other JavaScript developers think. And posting to other peoples opinion doesn't mean I agree with them.

23. I just hope I never ever run into code like this
Code:
```function validateForm(form) {
var email = form.email.value;
var age = parseInt(form.age.value);
var postNumber = parseInt(form.age.value);

if(!email.isValidEmail) {
return false;
} else if(age.isTooOld) {
alert("You are too old, you suck");
return false;
} else if(!postNumber.isValidPostNumber) {
return false;
}

return true;

}```

24. If those methods are defined in the javascript as well (which they would be) then it doesn't make a great deal of difference since you just look up the appropriate class for the info on how it is calculated. Encapsulating code like that is what object oriented processing is all about. To say that coding like that is wrong is saying that object oriented programming is wrong. Of course isTooOld is a rather ambiguous name and the property should have a better name that indicates what the upper age limit is (and perhaps also why).

25. Yes, I agree that encapsulating is very important. A new developer shouldn't need to know about the underlying implementation.

Java for example, has String, Date etc marked as final (meaning you can't subclass/extend). The SCJP book explanation why this is the case is kind of amusing:

"You'll notice many classes in the Java core libraries are final. For example, the String class cannot be subclassed. Imagine the havoc if you couldn't guarantee how a String object would work on any given system your application is running on!

If programmers were free to extend the String class, civilization - as we know it - could collapse."

My point is, that extending native objects and encapsulation are not related. If this would be the case, then encapsulation would not be possible in languages such as Java.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•