Module talk:Age/Archive 1

Module:Age
I created Module:Age to fix some problems reported with Age in years and months, and that template has been replaced with code to invoke this module. I don't know if it would be worth replacing other related templates with a call to a module, but as an experiment I have added code to this module to implement Age in days and Gregorian serial date. I have done over 100 tests offline which suggest that the module is performing correctly. The following shows a few results that compare the outputs from the current templates with User:Johnuniq/age days and User:Johnuniq/gsd which invoke the module.

I'll mention this in a couple of places to let people know the module is available. Johnuniq (talk) 09:55, 2 April 2013 (UTC)
 * Seems to be working well! Will it also work in e.g. Birth date and age?  It Is Me Here  t /  c  14:55, 11 June 2013 (UTC)
 * I'm super busy and can't take on any extra thinking for a while, however the short answer is that the module could fairly easily be extended to handle what I think the birth date and age template is doing, but it would need a bit of work and testing. Is there a known problem with the template? If so, that would focus my attention and make it more likely that people would want to accept a new solution to the very widely used dob template. It's a bit lucky that I noticed this. If you post here and I don't reply in a day or two, please ping my talk. Johnuniq (talk) 03:42, 12 June 2013 (UTC)
 * No problems as such that I know of; it's just that I thought that templates using Modules rather than template code loaded faster (esp. on mobile devices)? There's no rush; I just thought that if the bulk of the work has already been done, and that it would be a relatively easy matter to employ this code in other areas, it would seem a shame not to if it improves reader experience.  It Is Me Here  t /  c  10:54, 13 June 2013 (UTC)

Recent change
I just reverted the change to the module as it broke the module, adding over a hundred articles to Category:Pages with script errors. One change that broke things was the removal of age_ym but there was possibly others, I did not even try checking all the articles with errors but looked for the recent change that caused it.-- JohnBlackburne wordsdeeds 12:24, 24 June 2016 (UTC)
 * @JohnBlackburne: Thanks! Unfortunately there was a lot of off-wiki chaos here yesterday and I completely forgot to update age in years and months for the way the new module works. I did check a few things before I was called away, but the pages hadn't updated so I didn't see any problems. I have restored the new version and updated the template, and will be monitoring the situation. Johnuniq (talk) 01:01, 25 June 2016 (UTC)

Allow julianday month offsets to permit use in JULIANDAY
 Edit template-protected closed by author

JULIANDAY is the only template listed in the docs that doesn't use this module, and I believe it's because of edge cases involving leap years and too-large day-of-months in general, which the Age module rejects but the JULIANDAY template accepts. "1900-02-29" doesn't make sense in most other contexts, but it has a well-defined Julian day and is expected to work in the current JULIANDAY template (see testcases).

The edit I'm requesting fixes this compatibility issue by using an offset, and if it is accepted we should be able to finally replace JULIANDAY with this module so that all implemented template functionalities in the docs are actually used in their corresponding templates.

This edit only affects the  function, so it will not affect any non-Julian-day usage of the module. It's fully implemented in the module sandbox and it's been tested with all the JULIANDAY testcases. Here's the revised function:

local function dateToJd(frame) -- Return Julian date (a number) from a date which may include a time, -- or the current date ('currentdate') or current date and time ('currentdatetime'). -- The word 'Julian' is accepted for the Julian calendar. local Date = getExports(frame) local args = frame:getParent.args local date if args[1] and args[2] then date = Date(args[1], args[2], 1, args[4], args[5], args[6], args[7]) elseif args[1] then date = Date(args[1], 1, 1, args[4], args[5], args[6], args[7]) else date = Date(args[1], args[2], args[3], args[4], args[5], args[6], args[7]) end local offset = 0 if args[3] then offset = tonumber(args[3]) - 1 end if date then return tostring(date.jd + offset) end return message('Need valid year/month/day or "currentdate"') end

I can of course make any other changes if they help. Thanks, Habst (talk) 05:12, 17 June 2018 (UTC)
 * Please let's take some time to discuss this before moving to change the module. The only reason I haven't yet updated JULIANDAY to use the module is that I got distracted by other things. I updated the templates very slowly because the tracking categories can take a long time to catch up and show any problems, and I'm conservative about changing code. It also took quite a lot of work to fix old errors (invalid dates) in articles that the module reported. Thorough tests show that the module gives correct Julian days for all dates from 9999 BCE to 9999 CE (I wrote a test harness to check the first and last days of the month for all years in that range). The current template uses arithmetic that fails for dates well inside that range. For example,  (using the old template) gives -32410 whereas the module gives -32044. A reasonable argument could be made that it is silly to expect a Julian day for such an extreme date, but that's how it is. I will need 24 hours to think about the above. Meanwhile, the major advantage of the module IMHO is that it displays an error if an invalid date is used. Why would anyone want to know the Julian day of 1900-02-29 or 2018-04-31 (both of which are invalid dates)? Johnuniq (talk) 05:49, 17 June 2018 (UTC)
 * By the way, the module supports  which allow invalid dates to be entered. The date is adjusted by overflowing the day/month values. For example, using extract:
 * If  were omitted, the last of the above would show an error. If there was a reason for needing it, that parameter could be made available in JULIANDAY. Johnuniq (talk) 05:57, 17 June 2018 (UTC)
 * Hi, thanks for your points here and I agree we should discuss it. I have no problem using the current  function in JULIANDAY if that is acceptable -- the only reason why I modified the function to accept invalid dates were because invalid dates were being used in the test cases (which I didn't write) so I wanted to make them pass.
 * I agree that the Lua module is more accurate for larger magnitude dates, and I think that's a good reason to begin to use the module in the template (surely nobody would have depended on that incorrect behavior with the template arithmetic). Maybe using  is better than my offset change -- if it is, then we should use that instead. Or if nobody cares about knowing the date of 1900-02-29, then maybe we shouldn't use it at all. What do you think? --Habst (talk) 19:57, 17 June 2018 (UTC)
 * I would far prefer to have the template require valid dates and fix problems found where invalid dates are used. That is much better in the long run than accepting junk. I revert a dozen vandal attacks on articles each week when the bad edit damages a date in a template monitored by this module's error tracking category. Do you know of any reason to accept invalid or partial dates for JULIANDAY other than some test examples? I'll look at some examples of JULIANDAY in articles later. Johnuniq (talk) 23:31, 17 June 2018 (UTC)
 * I don't know of any examples; I only did it because of the testcases. If it's not used in practice and not documented, then there would be no harm in making the switch to the module either way. Do you think I should cancel this ER and make one at the JULIANDAY template to just use the unmodified module then? --Habst (talk) 23:43, 17 June 2018 (UTC)
 * I'll update JULIANDAY soon but I need to check my notes on the usage of that template first to gauge how many problems might occur. Johnuniq (talk) 01:21, 18 June 2018 (UTC)
 * I updated JULIANDAY to use Module:Age. It turns out the template was used in only half a dozen articles, but is used in about 20 templates which are used in around 12,000 articles. It is too hard to determine whether those templates can generate an invalid date, but a few cases that I checked only had valid dates. I will monitor Category:Age error to see if errors are reported. Johnuniq (talk) 03:56, 18 June 2018 (UTC)
 * OK, thank you! I'm marking this as resolved now. --Habst (talk) 05:20, 18 June 2018 (UTC)
 * I had to revert my edit so JULIANDAY is again using the old template code. Using the module there were hundreds of articles in Category:ParserFunction errors due to a handful of templates that I will investigate later: update after + show by date + PD-Australia and possibly others. That will be due to errors reported by the module with invalid dates but I'll check what's going on and do something in a day or two. Johnuniq (talk) 06:09, 18 June 2018 (UTC)
 * I updated JULIANDAY to use Module:Age. It turns out the template was used in only half a dozen articles, but is used in about 20 templates which are used in around 12,000 articles. It is too hard to determine whether those templates can generate an invalid date, but a few cases that I checked only had valid dates. I will monitor Category:Age error to see if errors are reported. Johnuniq (talk) 03:56, 18 June 2018 (UTC)
 * OK, thank you! I'm marking this as resolved now. --Habst (talk) 05:20, 18 June 2018 (UTC)
 * I had to revert my edit so JULIANDAY is again using the old template code. Using the module there were hundreds of articles in Category:ParserFunction errors due to a handful of templates that I will investigate later: update after + show by date + PD-Australia and possibly others. That will be due to errors reported by the module with invalid dates but I'll check what's going on and do something in a day or two. Johnuniq (talk) 06:09, 18 June 2018 (UTC)

The problem is that templates like update after can pass expressions in a parameter, such as  for the day. That works with the old template because everything is wrapped in a #expr and so is evaluated. The module would have to use  on each parameter if it's not a number. Problem: the module supports single-parameter dates, for example, these are the same (there is no comma for the first case since some templates expect a value without commas when used like this): I'll need a while to think about whether that can be supported for JULIANDAY while evaluating non-numbers as an expression. Johnuniq (talk) 09:52, 18 June 2018 (UTC)
 * → 3661 days
 * → 8579 days

Hmm, I tried something and will think about it later: Johnuniq (talk) 10:15, 18 June 2018 (UTC)
 * Show by mentions relative (e.g. +20 hours) times. The module can add/subtract date/time units but matching the syntax supported by #expr would be tricky. I'm starting to think there is no point in having the module implement JULIANDAY, apart from the fact that the module gives accurate results for weird dates that are unlikely to be used. Johnuniq (talk) 04:10, 20 June 2018 (UTC)
 * Thanks for your research on this . Why not have the template be a wrapper around the module that just s all its arguments first before passing them to the age module? --Habst (talk) 07:01, 20 June 2018 (UTC)
 * The templates supported by the module allow entry of a date in various formats, for example  or   or   or  . The time can also be included in each of these formats. The last example at 10:15, 18 June 2018 just above shows that the sandbox handles simple expressions—it tests each parameter to avoid trying to evaluate something like  . A problem is that it is not clear how JULIANDAY is being used—I haven't seen any examples of "+20 hours" in the docs mentioned just above, so I'm not sure what needs to be supported. One approach would be to switch the template to use the module again and see what breaks to determine what fixes would be needed in addition to what the sandbox does now. Johnuniq (talk) 07:21, 20 June 2018 (UTC)

Age/birth/death templates
The following templates are not implemented by Module:Age. They do not emit metadata.

The following templates are used in articles and emit metadata.

Examples showing the metadata emitted by the above templates. ( 2000-02-10 ) February 10, 2000
 * 1) 1  February 10, 2000

( 2000-02-10 ) February 10, 2000 (age&amp;nbsp;16)
 * 1) 2  February 10, 2000

( 2000-02-10 ) February 10, 2000 (aged 12)
 * 1) 3  February 10, 2000

10 February 2000 &amp;#160;( 2000-02-10 )
 * 1) 4  10 February 2000

February 2000 &amp;#160;( 2000-02 )
 * 1) 5  February 2000

2000 &amp;#160;( 2000 )
 * 1) 6  2000

2000 &amp;#160;( 2000 ) (age&amp;nbsp; 19)
 * 1) 7  2000

2 &amp;#160;( 2000 ) (age&amp;nbsp; 19)
 * 1) 8  2000

( 2012-02-23 ) February 23, 2012
 * 1) 9  February 23, 2012

February 23, 2012 (aged&amp;nbsp;45)
 * 1) 10 February 23, 2012

23 February 2012 &amp;#160;( 2012-02-24 )
 * 1) 11 23 February 2012

February 2012 &amp;#160;( 2012-03 )
 * 1) 12 February 2012

2012 &amp;#160;( 2013 )
 * 1) 13 2012

23 Feb 2012 &amp;#160;( 2012-02-24 ) (aged&amp;nbsp;12)
 * 1) 14 23 Feb 2012

Feb 2012 &amp;#160;( 2012-03 ) (aged&amp;nbsp;12)
 * 1) 15 Feb 2012

2012 &amp;#160;( 2013 ) (aged&amp;nbsp;12)
 * 1) 16 2012

February 23, 2012 (2012-02-23) (aged&amp;nbsp;12)
 * 1) 17 February 23, 2012

February 23, 2012 (2012-02-23) (aged&amp;nbsp;11–12)
 * 1) 18 February 23, 2012

February 23, 2012 (2012-02-23) (aged&amp;nbsp;11–12) Johnuniq (talk) 09:11, 12 January 2019 (UTC)
 * 1) 19 February 23, 2012
 * I asked at WT:WikiProject Microformats which of the above need to be fixed. Johnuniq (talk) 09:29, 12 January 2019 (UTC)
 * Some of those end date templates are outputting a year/month/day after the date entered as a parameter in the metadata. That's because they want the end date to be at the end or after the actual end date (including a time component), so just wondering if it would be better to not include the metadata at all if only the year or month is specified rather than adding on a year or month to the parameter value, and if a full date is specified, rather than adding a day onto that, include the time component in the metadata of 23:59:59 ? -- WOSlinker (talk) 12:10, 12 January 2019 (UTC)
 * I numbered each template to help identify them. I was wondering why, for example, #12 (February 2012) has metadata 2012-03. You are pointing out that the intention is for the metadata to identify a point in time that is guaranteed to be "the end". If someone died at 23:59 2012-02-29 then 2012-03 would be correct. A standard or local style guide would be nice. I don't really like the bloat in some of the above metadata and would be happier if it was documented as "should" somewhere. Johnuniq (talk) 02:41, 13 January 2019 (UTC)
 * I would recommend using the  element, if MediaWiki allows that in templates. That's preferable to using   to hide metadata. For example, #12 I would author as: February 2012 While we're at it, I would recommend adding microformats2 class names, so it would become: February 2012 I'll review this list of output and comment with other updates. – gRegor (talk • contribs) 01:14, 29 March 2019 (UTC)

Death dates in the future
I suggest adding Category:Age error for death dates more than one day in the future. Allow one day or 15 hours to account for time zones. [//en.wikipedia.org/w/index.php?title=Sydney_Brenner&diff=891013743&oldid=886668043 Example error] (now fixed). PrimeHunter (talk) 20:51, 5 April 2019 (UTC)
 * OK, I put that in the sandbox. The following shows what the sandbox produces for someone born on 1 Jan 2000 and who died yesterday, today, tomorrow, the day after tomorrow, and one month in the future.
 * What about Birth date and age? Perhaps birth dates in the future by more than one day should also raise an error? Some articles concern stories unrelated to real people and they could have future birth dates. I suppose showing an error (and the error category) would determine if that was a problem. Johnuniq (talk) 06:07, 6 April 2019 (UTC)
 * Oops, birth date and age already rejects birth dates in the future so this is probably ready for release. Johnuniq (talk) 09:56, 7 April 2019 (UTC)
 * Done, I updated Module:Age. Johnuniq (talk) 23:47, 7 April 2019 (UTC)
 * What about Birth date and age? Perhaps birth dates in the future by more than one day should also raise an error? Some articles concern stories unrelated to real people and they could have future birth dates. I suppose showing an error (and the error category) would determine if that was a problem. Johnuniq (talk) 06:07, 6 April 2019 (UTC)
 * Oops, birth date and age already rejects birth dates in the future so this is probably ready for release. Johnuniq (talk) 09:56, 7 April 2019 (UTC)
 * Done, I updated Module:Age. Johnuniq (talk) 23:47, 7 April 2019 (UTC)
 * Oops, birth date and age already rejects birth dates in the future so this is probably ready for release. Johnuniq (talk) 09:56, 7 April 2019 (UTC)
 * Done, I updated Module:Age. Johnuniq (talk) 23:47, 7 April 2019 (UTC)

Sorting will use data-sort-value
I changed Module:Age/sandbox with a minor enhancement for the  option and a change to how hidden sort keys work. Once this change is live, all templates implemented by this module (see list at Module:Age) will use data-sort-value for sort keys. This follows from a discussion regarding convert and val which will change in a similar manner.

The following shows some templates and the output from Special:ExpandTemplates.

data-sort-value="7002243000000000000"|over 243

 over 243

 over 8

 over 8&amp;nbsp;months

 before 1 September 1900 @TheDJ: Is the above ok? Johnuniq (talk) 07:41, 23 April 2019 (UTC)

Sorting in tables
A few years ago I saw that Template:age in years and days was being changed to remove the hidden sort key, and the template:ayd or template:age in years and days nts should be used in sortable tables. However, today while editing List of longest-living state leaders, I noticed that when sorting by age, the living leaders all bunched together. When I switched the template to template:age in years and days, this fixed even though if I understand the templates correctly that shouldn't have worked. Has something changed on the back-end or have I misunderstood the template? Emk9 (talk) 01:55, 27 April 2019 (UTC)
 * The following from Special:ExpandTemplates shows exactly what the templates output today:

&lt;span style="display:none" class="sortkey">7004368600000000000♠&lt;/span>100 years, 335 days

106 years 100 years, 335 days
 * ayd outputs a hidden sort key before the age, while age in years and days does not. The reason using the latter appears to be an improvement is that none of the ages for deceased leaders have a sort key, so it works better when the alive leaders also do not have a sort key.
 * The correct method would be to use ayd for every entry in the table—that would make all entries sort correctly. Problem: currently the deceased leaders have fixed text for their age. For example, Chau Sen Cocsal Chhum has "103 years, 143 days". The fix would involve getting the birth and death dates from the article and using them (the dates can use any reasonable syntax):
 * That would require quite a lot of work. An alternative would involve inserting a manual sort key which needs to be the age expressed in days. This example would be:
 * Using 365.25 instead of 365 would be slightly more accurate but probably not worth the trouble. Johnuniq (talk) 04:00, 27 April 2019 (UTC)
 * OK, that makes sense. Thanks Emk9 (talk) 05:52, 27 April 2019 (UTC)
 * Using 365.25 instead of 365 would be slightly more accurate but probably not worth the trouble. Johnuniq (talk) 04:00, 27 April 2019 (UTC)
 * OK, that makes sense. Thanks Emk9 (talk) 05:52, 27 April 2019 (UTC)

Template-protected edit request on 14 September 2019
There are some good templates for sortable tables: Could someone please add this for age in years and months also?
 * age in years and days -> age in years and days nts
 * age in years -> age in years nts
 * age in days -> age in days nts
 * age in years and months -> age in years and months nts Joseph (talk) 09:58, 14 September 2019 (UTC)
 * I could think about that but the fact that age in years and months nts was created less than an hour ago indicates that there has been no need for it in the past. At any rate, the module supports several parameters, one of which controls sorting:
 * → 22 years, 8 months
 * → 22 years, 8 months
 * → 22 years, 8 months
 * That is, a new template is not really needed. This should have started with a discussion, not an edit request, because the latter is used with a "complete and specific description of the request". Johnuniq (talk) 10:49, 14 September 2019 (UTC)


 * sortable=on works, thanks!.--Joseph (talk) 12:24, 14 September 2019 (UTC)

Localization of time zone for sr.wikipedia
Could someone help on how to localize this module for sr.wikipedia to Serbian Wikipedia's LOCALDAY i.e. local time in order to have calculation for CET/CEST and not UTC? It is used in birth date and age templates and wrongly calculates age if someone was born just year ago (e.g. displays zero years ago diff at local midnight and at local 1:00 one year ago [when CET and not CEST]) --5.43.82.5 (talk) 23:31, 2 March 2020 (UTC)
 * Probably not. The module assumes UTC the whole way through and has no localization facility because what it does is already sufficiently complicated; it's just a more accurate and consistent version of the templates that it replaced. However, if you provide a link to a page showing the problem and a brief description of what text on that page is the problem and why, I'll have a look. Are you saying that the servers for srwiki do not use UTC? Johnuniq (talk) 00:03, 3 March 2020 (UTC)
 * Thank you for answer. I cannot give you the article page that will always have wrong output but can give you example that you can test currently or other day near CET midnight (sr:Далибор Илић; you can find example for tomorrow's midnight on sr:5. март and choose any article listed in that* section that has full birth date (mostly recent ones, those lower in the list) *i.e. on Serbian Wiki's day+month article series in Births section. You can test it also with putting current day + 1 and current month with past year as a birth date on sr:Разговор са корисником:5.43.82.5 (currently it holds 3 March because I tested it on 2 March night when 3 March was about to come and expected "1 год."** at 3 March CET 00.00 but had "0 год." until 3 March CET 01.00 was the time), or in the sr.wikipedia's sandbox.
 * Yes, they do not. Both Belgrade and Banja Luka / Istočno Sarajevo as capitals of most numerous (by Serbian language speaking population) Serbian territories are located in CET/CEST timezone; that is why Serbian Wikipedia has that timezone for all LOCAL? magicwords, which are also used for main page 1-day intervals of changing e.g. featured picture (it changes now at 00.00 CET/CEST and not 01.00 CET or 02.00 CEST i.e. 00.00 UTC). That's why output problem occurs only from 23.00 UTC until 00.00 UTC (there is about [since my signature date] 37 minutes until it starts and 1 hour 37 minutes left until it gets correct output for todays problematic articles, 4 March births which will have for 2000 birth e.g. age displayed 19 and not 20 in the stated problematic period). **Problem is thus left-nsp-spaced bracket text generated by sr:Шаблон:Датум рођења, text number followed by left-spaced text "год.", both texts smalled in brackets. --5.43.82.5 (talk) 22:23, 3 March 2020 (UTC) [e]
 * Currently, you can see a problem until 00.00 UTC ("0 год." instead of "1 год."). And when I think more, I conclude that sr:Шаблон:Датум рођења should display age asof 12.00 CET/CEST (as well as English Template:Birth date and age at 12.00 UTC) because we should take into account time of birth which can vary from 00.00 till 23.59 that day, and because we do not know it the most probable (accurate) age guess would be at 12.00 in the time zone needed. --5.43.82.5 (talk) 23:11, 3 March 2020 (UTC)
 * I don't have time to examine the situation at the moment, but can you briefly explain why sr:Template:Датум рођења has so much wikitext? Google translate tells me it is Template:Date of birth and I see that it ends up calling Module:Age for the linked article, but why all the template wikitext? Can some adjustment be made there? Johnuniq (talk) 23:44, 3 March 2020 (UTC)
 * Because it is questioning many possible cases when only birth month and year e.g. are entered or day and year, etc. It is not Template:Date of birth but Template:Birth date and age, as already stated. It has incorporated param for yes/no display age (if person is alive / not alive). It calls Age module to calculate age if param "|год=" is yes/no yes, to give age in years ('година' is year in Serbian). I do not see need to simplify working code, expansion depth is not exceeded and it works fine and was tested for all possible combinations (as well as template for death date age which has even more combinations; that's why code is long). --5.43.82.5 (talk)

The module has no knowledge of time zones. It is an inherent "feature" of determining an age in years that it will jump by one year as the time passes midnight on the last day of a whole year: The above is unavoidable. It would be possible to insert a fudge factor so that once an age-in-years was within a certain number of hours before 1 year, that it would display 1 rather than 0.
 * → 1
 * → 1

There is no similar problem at enwiki because we use birth date and age (shown as the redirect bda below) and it calls Module:Age which shows ages in the appropriate units (days if less than a month old, months if less than 2 years old, otherwise, years). The following shows some simulated examples using fixed wikitext so it won't change in the future. I think you are saying that the problem at srwiki is that the age jumps forward by a year at UTC midnight when it should advance at CET midnight. I don't think you are going to get a satisfactory fix for that because the displayed text is when the page was last rendered by an edit or WP:PURGE. Even if the module were fixed, the age would still not roll over at CET midnight because the page showing the age is unlikely to be edited or purged at that time.
 * → 02:34 4 March 2020
 * → 4 March 2020 (age 0 days)
 * → 3 March 2020 (age 1 day)
 * → 5 March 2019 (age 11 months)
 * → 4 March 2019 (age 12 months)

However, if you want to remove UTC, remove  from the following line in sr:Module:Date:

Doing that would mean the date and age modules get the server local time rather than UTC. That would have the bad side effect of confusing the Julian date calculations which work with UTC but due to the purge lag I mentioned, no one would ever notice. Johnuniq (talk) 02:49, 4 March 2020 (UTC)


 * Yes, I say that (it jumps when UTC midnight and not CET/CEST). Thank you for all that extensive info. I don't known what do you mean for Julian but sr.wikipedia does not use it when calculating dates in birth and death date and age templates (always Gregorian date is entered, very simple), so there is no problem with that. Regarding purging, I know it cannot live-update just at midnight but I think when one loads an article page for first time on a new device with clear cache on it the article page gets refreshed to the last version of the article so it would display indeed wrong time if we do not apply that fix (removing that code in sr:Module:Date). The problem is probably solved now, or at least situation is better if page gets actually purged. That is the information I needed, that one about removing that line that forces UTC; I have just applied it. I would like your proposition how to have module age calculating time if end date not entered so current date applied (to make it assume half of the day and not beginning of the day because it is more possibly accurate to reflect current age that way). Thank you once more. --5.43.82.5 (talk) 03:20, 4 March 2020 (UTC)
 * No, that is not correct about "article page gets refreshed". MediaWiki caches all pages, that is, when an edit or purge occurs, the core of the page is converted to HTML and the HTML is stored in a special server as a cache. When anyone reads the page they see what comes from the cache, slightly modified for their status (e.g. skin if logged in). Here is a test:
 * My prediction is that editing this page or would update the above timestamp. However, just reading it will not.
 * Re your request, I would need a precise example of what you mean.
 * By the way, bnwiki localized Module:Age. The method is a bit ugly but it worked well enough for their needs. See bn:Module:বয়স. They use their equivalent of birth date and age which calls Module:Age directly without any of the stuff at srwiki (see bn:Template:জন্ম তারিখ ও বয়স. Johnuniq (talk) 04:07, 4 March 2020 (UTC)
 * OK, that is right. Just clean-loading the page does not refresh everything. Maybe there is auto purge sometimes but never mind, local time should be used anyhow.
 * Explanation is that if one was born on 4 March 2019 and currently is 00.00 4 March 2020 (4 March just began) template birth date and age does not display (after purge :)) age 1 year but still in months or so, and at 12.00 4 March 2020 (middle of 4 March) that it displays (after purge) age 1 year. My rationale is that because we do not enter birth time in birth date and age template it is wrong to assume that birth time is 00.00 o'clock but mean (middle, of the day – of the birth day, and then reflected into the end date for calculating age).
 * We prefer age in years always and pure code rather than taking care of cases for nouns or using inappropriate unfit or senseless abbreviations of three letters for three letter words (there are 7 cases in Serbian and we do not know how to adjust module to use different cases forms plus displayed text would be long and I mentioned problem with abbreviations). There are clear commentary notes in birth and death date and age templates on sr to easy follow what happens and it is fine-working. --5.43.82.5 (talk) 05:47, 4 March 2020 (UTC)
 * We prefer age in years always and pure code rather than taking care of cases for nouns or using inappropriate unfit or senseless abbreviations of three letters for three letter words (there are 7 cases in Serbian and we do not know how to adjust module to use different cases forms plus displayed text would be long and I mentioned problem with abbreviations). There are clear commentary notes in birth and death date and age templates on sr to easy follow what happens and it is fine-working. --5.43.82.5 (talk) 05:47, 4 March 2020 (UTC)

At what point does this module perform its calculations?
I wonder if anyone could clarify something for me, as either I have a long term misunderstanding of how templates based on this module works, or it is not working correctly. I've looked in the documentation and can't find anything that specifically identifies at what point the calculations occur.

If I, for instance, use the age in years and days template on a page like this;, at what point is the calculation for the years and days performed?


 * At the point I save my edit, and any subsequent edits by others?
 * At the point the page is requested/render by a browser?

I have always assumed, perhaps incorrectly, that it is the latter. But now it has been pointed out to me that the years/days shown by this template can be significantly out, because no-one has edited the page in some time. This suggests it is the former and my investigations suggest the same.

Is this always how it has been? Or something new, or what? Thanks.-- Escape Orbit (Talk) 17:51, 21 November 2020 (UTC)
 * Whenever the page cache for a page is reset/cleared/refreshed/whatever you want to call it, the templates being used on the page will be refreshed. Thus, it is possible that a page calculating a date could be +/- 1, depending on when it was last refreshed. This is how the software works, and there's not really anything that can be done about it. Primefac (talk) 19:49, 21 November 2020 (UTC)
 * I understand. However, it should be noted that it is not a matter of +/- 1.  The difference can be weeks/months. -- Escape Orbit  (Talk) 10:11, 23 November 2020 (UTC)
 * True. Doesn't change the fact that this is a technical limitation based on the way the system caches pages. Primefac (talk) 10:32, 23 November 2020 (UTC)
 * I explained a little more here. Johnuniq (talk) 00:27, 22 November 2020 (UTC)

PLURAL support
Is it possible for this module to utilize the plural magic word instead of the current plural implementation? This would be useful for localizing the module on wikis where a different form is needed depending on each of the numbers that the module outputs. – Srđan (talk) 07:54, 11 April 2021 (UTC)
 * I didn't worry much about localization because there are a lot of quirks that depend on the names of the months, days etc. Making something that properly handled i18n would be difficult and I don't know how much could be implemented using MediaWiki's interfaces. In particular, it is my strong opinion that a date like 1/4/21 should not be accepted because it is ambiguous in a global encyclopedia but last time I checked the built-in time functions decode it using US rules. When writing Module:Convert for use at other wikis I found that most people simply wanted a way to prevent the addition of s. Slwiki was very different with seven different possible names for a unit depending on the value. Do you have an example of a language and what it would want to do? Johnuniq (talk) 10:53, 11 April 2021 (UTC)
 * Yeah. For example, all Serbo-Croatian varieties (Bosnian, Croatian, Serbian) and some other Slavic languages use "Rule K" for plural (see the example column there). So, if I have PLURAL defined as NaN mjesecas for "month", kinda like here, it should output "mjesec" for 1, 21, 31..., "mjeseca" for 2–4, 22–24, 32–34..., and "mjeseci" for 5–20, 25–30... and so on for the year, week, day, hour, minute and second. – Srđan (talk) 09:05, 12 April 2021 (UTC)
 * Some very rough code below  that with some more tweaking might be of use? -- WOSlinker (talk) 09:55, 12 April 2021 (UTC)
 * I see what you mean. I'll have a look at what's involved in a couple of days. Remind me if I haven't posted here within a week (I'll ping you when I post). I gather the aim is to allow easier/better localization of the module for templates like age in years and months? That would provide a better output in the local language. However this proposal would do nothing for the input to the template which would have to be in English (unless rather heroic edits to the modules were performed). For the input, perhaps some kludge regarding translating local-to-en dates might occur before the module starts processing. I did some work for bnwiki two years ago but have forgotten the details—see a note regarding what they did here.@WOSlinker: Thanks but I think the aim is to have PLURAL evaluated (like expanding a template) so that the local MediaWiki would determine using local rules which parameter to use given the numeric value supplied. I'll have to ponder this later. Johnuniq (talk) 10:02, 12 April 2021 (UTC)
 * I've tried it in the sandbox with but the magic word is not being expanded.  -- WOSlinker (talk) 10:05, 12 April 2021 (UTC)
 * I have to go now so can't look at the moment. There's a Scribunto method for expanding a template and I assume it would work with a magic word. Johnuniq (talk) 10:11, 12 April 2021 (UTC)


 * I found this: mw:Extension:Scribunto/Lua_reference_manual which might be of use. I'm really bad at Lua, so I don't quite know if that's helpful or how to apply it if it is. P.S. Feel free to directly edit the sandbox version of the Module at bs.wiki. – Srđan (talk) 11:38, 12 April 2021 (UTC)
 * I've updated Module:Age/sandbox to use the convertPlural function (changes) but I'd like Johnuniq to check it before you used it. -- WOSlinker (talk) 13:54, 12 April 2021 (UTC)


 * Awesome. Will plural also work for txt-age and txt-aged? You should also be able to define if it's a prefix or a suffix; it's currently a suffix on bs.wiki, for example. – Srđan (talk) 15:03, 12 April 2021 (UTC)
 * Probably but might be more than I could manage. Ages are sometimes a range, so if the range was 4-5 then do you choose "mjeseca" or "mjeseci"? The coding would need to be done to just pass in the first value if it was a range to the plural function. -- WOSlinker (talk) 17:28, 12 April 2021 (UTC)
 * You would look at the last item in the range; so in that example, it would be "4–5 mjeseci" (equvivalent to if it were just "5"). Hopefully Johnuniq will take a look at that as well. – Srđan (talk) 18:07, 12 April 2021 (UTC)
 * I've started seriously looking at this but will need a few days due to off-wiki turbulence. I tried to convince myself that it would be worthwhile to have a special case for English (just add "s" rather than call the language plural function) but it's not. I'll attend to a couple of other issues mentioned above. Johnuniq (talk) 07:40, 15 April 2021 (UTC)
 * Things went faster than expected and I have updated Module:Age/sandbox. However, I'll need a couple of days to check it. Johnuniq (talk) 10:37, 16 April 2021 (UTC)

I finished work on localizing Module:Age/sandbox and have requested that it be used to update the main module at bswiki (bs:User talk:Srđan) and at bnwiki (bn:User talk:Johnuniq). Johnuniq (talk) 03:36, 20 April 2021 (UTC)

Add support for Duration in years, months, weeks and days
There is currently no way to correctly format the duration between two dates in the same way Age in ... does. There's only Template:Duration in days. It seems that in many places the Age template is often incorrectly used instead. The change should be fairly trivial by adding the below snippet to https://en.wikipedia.org/wiki/Module:Age#L-703:

duration_ymwd = {          -- show = 'ymwd', duration = true, }, Phiarc (talk) 15:29, 11 March 2022 (UTC)
 * Confusing – there is no Duration in years, months, weeks and days. The Age template is designed only to give the number of years. So what is it exactly that you are proposing?  P.I. Ellsworth &numsp;- ed.  put'r there 20:05, 11 March 2022 (UTC)
 * I never got the strength to update the documentation for all the templates that now use Module:Age. In fact, all the parameters mentioned at the module page can be used.
 * I don't think it's worth adding more templates when all that's needed is the  parameter. Johnuniq (talk) 22:35, 11 March 2022 (UTC)
 * Well, you and I could always go fishin' and I could getcha with the first trout I catch.  P.I. Ellsworth &numsp;-  ed.  put'r there 02:01, 12 March 2022 (UTC)
 * I don't think it's worth adding more templates when all that's needed is the  parameter. Johnuniq (talk) 22:35, 11 March 2022 (UTC)
 * Well, you and I could always go fishin' and I could getcha with the first trout I catch.  P.I. Ellsworth &numsp;-  ed.  put'r there 02:01, 12 March 2022 (UTC)