Template talk:Age in years and days

From Wikipedia, the free encyclopedia

Contents

[edit] Leap years

This template does not seem to take leap days into account. I tried measuring from Feb. 28 to Mar. 1 of the following year; 1995-1996 should be "1 year, 2 days" and 1994-1995 should be "1 year 1 day", but both are the later:

  • For 1994-5: &0000000000000001.0000001 year, &0000000000000001.0000001 day
  • For 1995-6: &0000000000000001.0000001 year, &0000000000000002.0000002 days
  • For 1996-7: &0000000000000001.0000001 year, &0000000000000001.0000001 day

I think I've found a way to fix it. --Arctic Gnome (talkcontribs) 23:11, 17 July 2007 (UTC)

After a bunch of testing, I seem to have got it to work with leap years without screwing up the rest of the functions. --Arctic Gnome (talkcontribs) 00:17, 18 July 2007 (UTC)
I have also fixed the problem that was stopping this template from working right for times less than one year. --Arctic Gnome (talkcontribs) 00:58, 18 July 2007 (UTC)
Thanks and well done Arctic.gnome. —Moondyne 01:38, 18 July 2007 (UTC)
No problem, it was a very educational experience for myself; I'm just starting to get the hang of the "if" statements. I've now also fixed the plurals so if there is only one year it says "year" rather than "years". --Arctic Gnome (talkcontribs) 02:06, 18 July 2007 (UTC)

[edit] Protected

This a great template, kudos to Moondyne for making it. I think this will eventually be in many tables, so I've gone ahead and protected it. --Arctic Gnome (talkcontribs) 02:12, 18 July 2007 (UTC)

Actually, it was User:Hesperian who created it [1] on my request. He gets the credit. —Moondyne 07:46, 20 July 2007 (UTC)

[edit] Invalid dates

I think this is a great template, and it will come in very handy for many. However, I was playing around with the template, and I noticed that it "allows" the user to input invalid dates. In other words, the template allows for input of the following three types of invalid dates:

  • (a) dates that do not exist, such as February 30 or February 31;
  • (b) leap days of February 29 in non-leap years (e.g., February 29, 2004 should be allowed as input, but February 29, 2005 should not); and
  • (c) month and day values that are out of range (e.g., one can input a 99 for the month or a 77 for the day, etc.).

All of these invalid dates should not be "allowed" as input ... nonetheless, they yield numerical results (which I assume are incorrect calculations). Is there any way to fix this? Thanks. (Joseph A. Spadaro 19:55, 7 August 2007 (UTC))

It would be possible to go through and tell the template to give an error result for incorrect dates, but I do not think that this is necessary. This template essentially just takes two other templates: {{age}} and {{age in days}} and puts all of the numbers in the right place in each of them. Those two templates are big ones used in tens of thousands of articles, and if you were going to tell a template to start giving error messages for bad dates, it should be there. I think that for those two templates it has been assumed that editors of articles in which they are used should make sure that the dates are correct rather than having the template put a "cannot compute" message in the middle of articles. --Arctic Gnome (talkcontribs) 21:38, 7 August 2007 (UTC)
Thanks for the background info on the template. That is helpful to know. Now, of course, it is assumed that editors should and will input correct dates into articles and formulas. However, that is why they are called "errors" -- because they occur inadvertently as opposed to intentionally. Typically, I would assume, through typo's. The fact that these formulas spit out some form of output (I assume incorrect calculations) -- as opposed to an error message -- simply makes errors that much harder to detect and/or avoid. That is, the algorithm should not even accept a "date" such as 99/99/99 ... much less perform calculations on it. Thanks. (Joseph A. Spadaro 01:14, 9 August 2007 (UTC))
You could use the same argument that the results are incorrect of the input values are entered wrongly. eg. digits in a year being transposed. GIGO. —Moondyne 01:29, 9 August 2007 (UTC)
Well, of course. One could put forth many arguments. However, transposing the year "82" to "28" -- while still an error -- ultilizes feasible input of a correct or valid year. That is, even though the entry "28" (or "82") may be an error in this particular case, it can also be a non-error in another particular case. Unlike ... say ... entering a month of "99" ... which is guaranteed to be an error in any and every case (as "99" will never be a valid entry for a month). It's simply one more way to catch / prevent / avoid errors -- that is all that I am saying. Furthermore, if indeed the algorithm calculates some values (results) based on invalid entries, there clearly must be some error within the algorithm. For example, let's input two invalid dates: 55/55/1955 as the beginning date and 88/88/1988 as the ending date. In this case, the formula calculates a result of "33 years and 1039 days" as the age. Where and how is this non-sensical value arrived at? The fact that any result at all is being calculated indicates that there is some inherent error within the algorithm. Furthermore, the fact that output of "1039 days" is calculated as the result further indicates an inherent error within the algorithm. That is, the algorithm should never -- regardless of input -- output more than 365 days ... any amount above and beyond 365 days should simply increase the year value by 1 and start the index for days over again at 0. In other words, there should never be an output that reads "370 days" -- rather, it should read "1 year and 5 days". The number of days should never exceed 365 and the fact that it does indicates an inherent error within the algorithm. Thanks. (Joseph A. Spadaro 01:46, 9 August 2007 (UTC))
An error message would be useful, but as a second choice, to detect an input error an output "370 days" is more useful than "1 year and 5 days".--Patrick 06:25, 9 August 2007 (UTC)
I don't disagree with those comments, but going back to your original question: Is there any way to fix this?, Arctic.gnome answered above that such error checking and feedback would ideally need to be done at the higher level templates rather than here. I am sure that it could be done but the downside is that such checking would probably add a lot of code to these widely used templates and I would guess that the work required and the overheads in having larger templates are just not warranted. Templates are just shortcuts to save writing more complicated wikimarkup and I don't think they are generally intended as bulletproof interfaces. I say again, GIGO. Cheers. —Moondyne 04:45, 9 August 2007 (UTC)
We can't tell the template to add one to the year when the days are more than 365 because the year and the days are calculated using two completely separate templates: {{age}} and {{age in days}}. The first template calculates the year, then the second one calculates the number of days remaining in the last year (doing the last year lets us get the leap days right). If someone enters an invalid date, the two other templates treat it as that many days after the last valid date; thus March 40th = April 9th. Fixing it here would either require telling this template to look out for a slew of possible errors which would take forever; or to re-write the entire calculator from scratch, which I don't know how to do. It still seems best to me to take this issue to the two super-templates. --Arctic Gnome (talkcontribs) 05:36, 9 August 2007 (UTC)
I added some documentation at Template:Age/doc about wrong input.--Patrick 06:20, 9 August 2007 (UTC)
I can understand and appreciate all of the above comments. Realistically and practically, then ... perhaps the least we can do is to add some sort of notation / disclaimer to this template page as well ... (somewhat similar to the notes added by Patrick to the Template:Age/doc) ...? Thanks. (Joseph A. Spadaro 22:15, 9 August 2007 (UTC))
I added some documentation at Template:Age in years and days/doc about wrong input, consistent with the documentation added by Patrick at Template:Age/doc. Given the thread of conversation above and the cost/benefit considerations of editing the current code, I think that the documentation about the input of invalid dates is a satisfactory solution. (Joseph A. Spadaro 22:28, 14 August 2007 (UTC))

[edit] Commas

Greetings,

The template as currently written gives ages with commas. I was wondering, would it be possible to have a template that does not give commas? Modern usage has tended to not use commas in this instance because a person's age is simply one number. Hence, if someone is 17.45 years old, we are given one age. To say that someone is "17 years, 45 days old" seems a bit laborious when it comes to reading long lists, as happens with the article List of living supercentenarians.

Sincerely, Robert Young Ryoung122 06:50, 9 August 2007 (UTC)

I am not sure that I am understanding your question. Are you stating (or implying) that both of those values you cite are the same value (i.e., that "17 years, 45 days old" is the same age value as "17.45 years old")? For they are not. In the first case (with the comma that you are objecting to), the numeral 45 refers to the absolute number of days. In the second case (with the decimal point), the numeral 45 refers to a decimal (or fractional) part of a year (i.e., specifically 0.45 of a year = 45% of a year = 164 days). Two very different values. And I have never seen the convention where a notation as 17.45 is used to represent 17 years and 45 days. Please clarify your question. Thanks. (Joseph A. Spadaro 07:03, 9 August 2007 (UTC))
No, I am implying that when we use a decimal place, we recognize a person's age as one value: 17.12 years old. When using the day and date template, it recognizes a person's age as two values: "122 years, 164 days old" for Jeanne Calment instead of "122 years 164 days old." I like the lack of a comma because it helps the reader better understand that a person's age is just one value. This may not seem like a big deal until the age list is in the 'hundreds' range.Ryoung122 07:16, 9 August 2007 (UTC)
Ryoung asked me this question a couple of weeks ago and I answered that I thought commas seemed to be more correct grammatically. On reflection I'm not so sure of my answer and so would like to hear others thoughts. If it was a vote, I'd probably say Weak keep for commas but could be swayed. —Moondyne 13:06, 9 August 2007 (UTC)
My thoughts are as follows. The main objection to the use of commas is merely aesthetic. And, even at that, there is scant little aesthetic difference between the values being listed with the comma versus without the comma. As far as grammar, I would contend that inclusion of the comma is grammatically correct. For example: if we declared that an age was 73 years, 4 months, and 16 days ... I think it's clear that the commas are necessary. First, it is grammatically correct. Second, it would be quite cumbersome (and hard on the eyes) to make sense of a string such as: 73 years 4 months 16 days. (It is "too" compact -- and needs some visual / aesthetic separation ... i.e., comma usage.) So, if I had to choose between "37 years, 95 days" (with comma) or "37 years 95 days" (without comma), I would advocate the former (include the comma). Therefore, a KEEP vote. Another consideration ... not one that I necessarily endorse ... is the format "37 years and 95 days" (replace the comma with the word "and"). Just a thought in that it does two things: (a) keeps the phrase compacted as one -- so that the age is recognized as one, not two, values; and (b) the word "and" provides enough visual and aesthetic separation (in lieu of the comma) so as to make the info manageable and not cumbersome to read / digest. Thanks. (Joseph A. Spadaro 22:33, 9 August 2007 (UTC))

Greetings,

This seems to be an issue of style. Newspapers and book publications (including Guinness World Records) do NOT use commas for age (or the use of 'and'). The main reason is to save printing space (lowering cost and increasing efficienty, important with books that have to cut some material to meet a page limit). However, it has an added benefit: efficiency for the reader. One can read the age 'faster' without the , because one's mind has been trained to slow down when it sees a comma (like a 'yellow light' on the information superhighway). Further, it seems the best example of why 'not' to use them is the one you cited: 73 years, 4 months, and 16 days. It sounds like reading a novel. It is also old-fashioned and technically incorrect. Why? Because some months have 31 days; some have 30 days; February has 28 or 29 days. Comparing ages, then, requires the use of a 'day' counter, without 'months'...a 'day' is always the same for everyone. It makes sense to use commas for a novel but not for tables/graphs/mathematical formulas/etc. Note that using a comma could mess up an 'Excel' formula calculation.

The last reason is that the , implies movement, but most of the people on the longevity lists are dead and the age isn't going to change. Thus, it looks a bit visually distracting to have it there. It's a minor issue but in the long run, efficiency and readability argue for 'no commas' when an age is given in a table format.

However, this need not be an either/or proposition: perhaps two versions could be made (one with a comma and one without). The comma is better for use with the 'written word'/dialogue. Just an idea.

Sincerely, Robert Young Ryoung122 06:58, 10 August 2007 (UTC)

I would oppose a second template as that would just lead to disagreements and one of the templates would sooner or later end up at TfD. We need to establish a consensus and move forward. I posted a question at the MOS talk page for wider input.. —Moondyne 07:56, 10 August 2007 (UTC)

I think that we should keep the commas as per Joseph. It seems grammatically correct to have a comma there, and since this will mostly be used in lists, I do not foresee a problem with the flow and pacing of the text being slowed. --Arctic Gnome (talkcontribs) 14:27, 10 August 2007 (UTC)

Regardless of the comma's position, "age ... old" is a tautology. Use "John Smith's age is 28 years 315 days" or "John Smith is 28 years 315 days old". Why not replace the comma with "and" ?Andy Mabbett | Talk to Andy Mabbett 16:59, 10 August 2007 (UTC)
We could probably add a parameter that would give people the option of taking out the comma or replacing it with "and", but that would make this already large template even bigger. If someone has a big problem with the comma, it might be best to have two separate templates. --Arctic Gnome (talkcontribs) 16:23, 16 April 2008 (UTC)

[edit] Missing protection template

{{editprotected}}

Someone needs to add the {{Protected template}} to this page. It's confusing some editors who come here and realize they can't edit it. Thanks. Hersfold (t/a/c) 20:12, 21 August 2007 (UTC)

Done. — Carl (CBM · talk) 00:05, 22 August 2007 (UTC)
Thanks. (Joseph A. Spadaro 00:24, 24 August 2007 (UTC))

[edit] Infant age

Is it possible to change the parameterization or make a similar template for an infants age so that it reads (age 3 mos. and 14 days.) below age 1 and (age 1 yr. and 3 mos.) between 1 yr and 2 years and just (age 3) above 2 years.--TonyTheTiger (t/c/bio/tcfkaWCDbwincowtchatlotpsoplrttaDCLaM) 14:07, 2 October 2007 (UTC)

In case you are wondering about usage an example would be the Children section of Tiger Woods' infobox.--TonyTheTiger (t/c/bio/tcfkaWCDbwincowtchatlotpsoplrttaDCLaM) 14:08, 2 October 2007 (UTC)

[edit] Years, months, days

Is there a template for calculating age in Years, months, and days?—Markles 00:02, 3 December 2007 (UTC)

[edit] Too many on one page?

There reached a point on List of living former United States Senators where the templates information does not appear. Is there a reason for this? When it starts this, it says "Expression error: Unexpected < operator". (Star Garnet 19:30, 15 December 2007 (UTC))

That is very odd, the system just doesn't want to process templates after a certain number of them. I can't think of anything on this template that would cause that; you may have to talk to people who know more about how the wiki-system as a whole processes information. --Arctic Gnome (talkcontribs) 20:19, 15 December 2007 (UTC)
I've seen this problem before. It seems to be a temporary problem with MediaWiki, not the page or the template. Sit back and relax. It should fix itself… I hope.—Markles 20:32, 15 December 2007 (UTC)
Due to the pre-expand include size maximumhttp://en.wikipedia.org/wiki/Wikipedia:Template limits of 2,048,000 bytes you can only call this template a little more than 100 times on a page.--Patrick (talk) 23:58, 15 December 2007 (UTC)
Well, then we're screwed. Can anyone create a work-around?—Markles 01:12, 16 December 2007 (UTC)
  • The {{age in days}} template has been changed so that it no longer needs to have parameters like "year1=" in it, meaning I can make the code for this template much smaller. Maybe that would help. --Arctic Gnome (talkcontribs) 02:01, 16 December 2007 (UTC)
  • Okay, so I was not able to shorten it as much as I hoped, I've allowed for one extra calculation per page. It takes up a lot of space to make this template subtract the total years from the {{age in days}} template. I think your best bet is to just list their ages by years rather than giving the exact number of days. For people who have passed on, you can subst: this template and fit many more numbers into an article.
  • I've found another way to make it have to do a bit less processing, but now it will use plurals when it shouldn't on January 1st and February 29th, giving "1 days" rather than "1 day". I don't think having bad grammar every few years is worth getting two extra usages per page. --Arctic Gnome (talkcontribs) 03:06, 16 December 2007 (UTC)
I made an adjustment so that the number of days is computed only once, now the capacity is 1.5 times what is currently on List of living former United States Senators.--Patrick (talk) 09:44, 16 December 2007 (UTC)
A subpage? Very clever, I'm impressed. --Arctic Gnome (talkcontribs) 19:55, 16 December 2007 (UTC)