Template talk:IsLeapYear

message: In 2008, the  template will be "one-off". Maybe we can use isLeapYear to fix this problem in advance. --Uncle Ed 15:02, 27 April 2006 (UTC)
thread_title: Uses

message: It looks like this expression can be shortened (e.g.)
*CURRENTYEAR 
*CURRENTYEAR 
*1600 
*1700 
*1800 
*1900 
*1999 
*2000 
*2001 
*2002 
*2003 
*2004 
*2005 
*2006 
*2007 
*2008 
*2009 
*2010 
*2011 
*2012 
*2013 
*2100 
*2200 
*2300 
*2400 
*2800 
This looks like it works and uses less cycles, though it may fail in 2800CE.
— xaosflux Talk 03:33, 28 April 2006 (UTC)
replies: text: I added a few more test cases; your code fails for years evenly divisible by 100 (but not divisible by 400). :( If you can get it working with those tests though, feel free to update it. (It does seem to work for 2800 though). —Locke Cole • t • c 03:45, 28 April 2006 (UTC)
replies: text: Thanks, will get back on this tonight, think i have a not in the wrong place. — xaosflux Talk 12:12, 28 April 2006 (UTC)
thread_title:  tighter code? 

message: In english: If the date is (divisible by 4 and not divisible by 100) or (divisble by 400) then it's a leap year. — xaosflux Talk 17:24, 29 April 2006 (UTC)
thread_title:  tighter code-try 2 

message: *1600 
*1700 
*1800 
*1900 
*1999 
*2000 
*2001 
*2002 
*2003 
*2004 
*2005 
*2006 
*2007 
*2008 
*2009 
*2010 
*2011 
*2012 
*2013 
*2100 
*2200 
*2300 
*2400 
*2800 
* — xaosflux Talk 17:15, 29 April 2006 (UTC)
thread_title: Test Data tight-2

message: There was a  in this template that converted it to using the  parser function. I'm copying below (with some adaptations) a discussion that occurred at Template talk:LastLeapYear, to get more feedback, and because it ended up being about this template instead. --Waldir talk 01:22, 2 May 2011 (UTC)
replies: text: I'd like to have this work with pure arithmetics rather than recurring to other functions, though. I'll take a look at the implementation of the #time parser function. --Waldir talk 23:38, 30 April 2011 (UTC)

text: * Not surprisingly, MW seems to ultimately end up pointing to php's gmdate() (after some internal formatting). I'll investigate further. --Waldir talk 23:59, 30 April 2011 (UTC)

text: * Can you believe it? I followed the trail (looks like they make it hard on purpose, I must say), and ended up here:#define timelib_is_leap(y) ((y) % 4 == 0 && ((y) % 100 != 0 || (y) % 400 == 0))So we're back at the beginning, with the exact same code we started off with :) --Waldir talk 00:46, 1 May 2011 (UTC)

text: * Btw, don't you think 's code would be more intuitive if we restored the previous version? --Waldir talk 22:39, 1 May 2011 (UTC)
replies: text:  I think we should use MediaWiki parser functions whenever possible, since they will be generally faster, and more concise.  The algorithm is still in the documentation.  I personally find  very concise and clear, since I can just look up the "#time" function in the MediaWiki documentation.  The ability to leverage these functions for date arithmetic has massively simplified many of the date arithmetic templates. Just my two cents.  Plastikspork ―Œ(talk) 22:48, 1 May 2011 (UTC)
replies: text:  In this case I can't see how this could be faster, since it's executing the exact same arithmetic operations as the template had before. The general case might be so, but in this specific case it doesn't apply, it seems. Also, it might be more concise, but it's certainly less clear, since one needs to look up the MW documentation to figure out what that does. Let's wait for other opinions. --Waldir talk 01:22, 2 May 2011 (UTC)
thread_title:  Use mediawiki builtin function?