SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 26
  1. #1
    SitePoint Zealot maileen's Avatar
    Join Date
    Apr 2006
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question 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. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Code:
    var isLeapYear = function(year) {
      var d = new Date();
      d.setYear(year);
      d.setMonth(1);
      d.setDate(29);
      return d.getDate() == 29;
    }

  3. #3
    HardCoder md_irfan_amu's Avatar
    Join Date
    May 2005
    Location
    Asia
    Posts
    215
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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 ???
    Irfan
    Find Tutors Easyway to get connect with your tutor in india

  4. #4
    HardCoder md_irfan_amu's Avatar
    Join Date
    May 2005
    Location
    Asia
    Posts
    215
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    }
    Irfan
    Find Tutors Easyway to get connect with your tutor in india

  5. #5
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by md_irfan_amu View Post
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  6. #6
    HardCoder md_irfan_amu's Avatar
    Join Date
    May 2005
    Location
    Asia
    Posts
    215
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    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...
    Irfan
    Find Tutors Easyway to get connect with your tutor in india

  7. #7
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #8
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #9
    SitePoint Wizard siteguru's Avatar
    Join Date
    Oct 2002
    Location
    Scotland
    Posts
    3,629
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by md_irfan_amu View Post
    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.
    Ian Anderson
    www.siteguru.co.uk

  10. #10
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by siteguru View Post
    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. #11
    SitePoint Zealot the DtTvB's Avatar
    Join Date
    Jul 2006
    Location
    Thailand
    Posts
    162
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #12
    SitePoint Addict jtrelfa's Avatar
    Join Date
    Oct 2004
    Location
    Troy, Mi
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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);
    };
    
    //your code
    var testDate = new Date("5/1/2000");
    alert (testDate.isLeapYear()); //true
    var me = null;

  13. #13
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by md_irfan_amu View Post
    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.

    Quote Originally Posted by md_irfan_amu View Post
    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. #14
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #15
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And? Do you expect them to have different opinions on what a leap year is?

  16. #16
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #17
    SitePoint Addict jtrelfa's Avatar
    Join Date
    Oct 2004
    Location
    Troy, Mi
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Pepejeria View Post
    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.
    var me = null;

  18. #18
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #19
    SitePoint Addict jtrelfa's Avatar
    Join Date
    Oct 2004
    Location
    Troy, Mi
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Pepejeria View Post
    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.

    To answer your other question:
    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.
    var me = null;

  20. #20
    SitePoint Addict jtrelfa's Avatar
    Join Date
    Oct 2004
    Location
    Troy, Mi
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    var me = null;

  21. #21
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  22. #22
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jtrelfa View Post
    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. #23
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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) {
    		alert("Email not valid");
    		return false;
    	} else if(age.isTooOld) {
    		alert("You are too old, you suck");
    		return false;
    	} else if(!postNumber.isValidPostNumber) {
    		alert("Not a valid number");
    		return false;
    	}
    	
    	return true;
    	
    }

  24. #24
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    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).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  25. #25
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

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