Template talk:Time interval

Discussion
@JFG and Huntster: Please examine the above and let me know what you think of the proposed syntax. It would be great if you would do some checking. For more time precision, use  or. Due to a copy/paste blunder which I have fixed, I'm not sure if my first ping worked, so am sending again; sorry if it's twice! Johnuniq (talk) 11:21, 6 June 2016 (UTC)


 * I am absurdly excited about this. Let's see, notes. Documentation should specifically note that times are calculated as UTC, so local yokels who think their city is the center of the universe don't confuse things (sorry, been dealing with local times in articles a lot lately). Yep, that's it. I've tested on a large number of pages without any noticeable errors. Looks damn solid to me. — Huntster (t @ c) 19:03, 6 June 2016 (UTC)
 * Thanks for the feedback. I added some documentation that can be seen at the template. Please think about the syntax and whether anything should be changed. What other features are needed? I'm going to think about handling "partial" dates—currently I suppose cases like "1990" or "June 1990" or "1990 June" could be handled, but more complexity than that could be tricky. Johnuniq (talk) 01:08, 7 June 2016 (UTC)
 * I think that supporting whole years might be okay, but perhaps Month Years might be too ambiguous to convert from? I don't know. — Huntster (t @ c) 04:37, 7 June 2016 (UTC)
 * Also, when "abbr=on" is set, I wonder if comma separators (no "and") should be defaulted on since they are used in the full default mode. — Huntster (t @ c) 14:25, 7 June 2016 (UTC)
 * I'm missing something. Here are some examples of current behavior:
 * What is an example of what should happen? Johnuniq (talk) 11:07, 8 June 2016 (UTC)
 * Sorry, what I meant was that perhaps when "abbr=on" is set, the default behaviour should be to output "1 yr, 2 mos, 3 days" rather than having no commas, since "abbr=off" (true default) includes commas. I was just thinking out loud, but it seemed like that might be expected behaviour. — Huntster (t @ c) 03:14, 9 June 2016 (UTC)
 * Sorry guys, didn't take time to comment earlier. Quick remark here: on should probably display "1y 2m 3d" not "1 yr 2 mos 3 days" which doesn't look much abbreviated... I see you introduced an option letter to get the compact format but I think that should be the default behaviour of on. If we need partial abbreviations like "1 yr 2 mos 3 days", let's call them partial or some such; looks like a less-usual case to me. — JFG talk 10:14, 9 June 2016 (UTC)
 * I would also allow the more natural, to use commas, or in fact sep could contain anything the user might want to use as separator. — JFG talk 10:20, 9 June 2016 (UTC)
 * (I prepared this before seeing JFG's comment—will ponder that later.)
 * I'm happy with whatever is wanted, but the current result was to emulate what age for infant does:
 * If {time interval} should display commas between the units for the above numbers, what about the abbreviations themselves? The singular abbreviations are yr, mo, day; the plural abbreviations are yrs, mos, days. That can be changed at any time so it's not a big deal, but I don't see why an abbreviation would have a plural—"mos" looks strange to me. The age_for_infant template is only used about 100 times, and only four of those have abbr=yes, and it only matters in two cases (1 yr 3 mos and 1 yr 10 mos). I like consistency so {time interval} would ideally give the same results as {age for infant}, but as it only occurs twice it doesn't matter and {time interval} can do whatever we want. Johnuniq (talk) 10:24, 9 June 2016 (UTC)
 * John, since it was designed to emulate "age for infant" in this case, disregard my comments; it was just a thought. Regarding JFG's comment, I tend to agree that "y m d" should be used instead of "yrs mos days"; yes, "mos" looks very odd, so I'd question whether a partial form should even be included as an option. — Huntster (t @ c) 16:30, 9 June 2016 (UTC)
 * Sorry guys, didn't take time to comment earlier. Quick remark here: on should probably display "1y 2m 3d" not "1 yr 2 mos 3 days" which doesn't look much abbreviated... I see you introduced an option letter to get the compact format but I think that should be the default behaviour of on. If we need partial abbreviations like "1 yr 2 mos 3 days", let's call them partial or some such; looks like a less-usual case to me. — JFG talk 10:14, 9 June 2016 (UTC)
 * I would also allow the more natural, to use commas, or in fact sep could contain anything the user might want to use as separator. — JFG talk 10:20, 9 June 2016 (UTC)
 * (I prepared this before seeing JFG's comment—will ponder that later.)
 * I'm happy with whatever is wanted, but the current result was to emulate what age for infant does:
 * If {time interval} should display commas between the units for the above numbers, what about the abbreviations themselves? The singular abbreviations are yr, mo, day; the plural abbreviations are yrs, mos, days. That can be changed at any time so it's not a big deal, but I don't see why an abbreviation would have a plural—"mos" looks strange to me. The age_for_infant template is only used about 100 times, and only four of those have abbr=yes, and it only matters in two cases (1 yr 3 mos and 1 yr 10 mos). I like consistency so {time interval} would ideally give the same results as {age for infant}, but as it only occurs twice it doesn't matter and {time interval} can do whatever we want. Johnuniq (talk) 10:24, 9 June 2016 (UTC)
 * John, since it was designed to emulate "age for infant" in this case, disregard my comments; it was just a thought. Regarding JFG's comment, I tend to agree that "y m d" should be used instead of "yrs mos days"; yes, "mos" looks very odd, so I'd question whether a partial form should even be included as an option. — Huntster (t @ c) 16:30, 9 June 2016 (UTC)
 * If {time interval} should display commas between the units for the above numbers, what about the abbreviations themselves? The singular abbreviations are yr, mo, day; the plural abbreviations are yrs, mos, days. That can be changed at any time so it's not a big deal, but I don't see why an abbreviation would have a plural—"mos" looks strange to me. The age_for_infant template is only used about 100 times, and only four of those have abbr=yes, and it only matters in two cases (1 yr 3 mos and 1 yr 10 mos). I like consistency so {time interval} would ideally give the same results as {age for infant}, but as it only occurs twice it doesn't matter and {time interval} can do whatever we want. Johnuniq (talk) 10:24, 9 June 2016 (UTC)
 * John, since it was designed to emulate "age for infant" in this case, disregard my comments; it was just a thought. Regarding JFG's comment, I tend to agree that "y m d" should be used instead of "yrs mos days"; yes, "mos" looks very odd, so I'd question whether a partial form should even be included as an option. — Huntster (t @ c) 16:30, 9 June 2016 (UTC)

I uploaded a new version with these changes: I think I'll wait before implementing —is it really needed? Something more general might be better, perhaps like a very simple printf. I'll update the documentation in due course. Let me know if anything else is needed. Johnuniq (talk) 08:08, 10 June 2016 (UTC)
 * For time interval:
 * no longer exists (see the error message in my table at top).
 * now shows letters as in "1y 2m 3d", example:
 * has the same effect as.
 * Partial abbreviations such as yrs and mos are not supported.
 * For age in days (if implemented by Module:Age):
 * shows "d" (by default, only the number of days is shown).
 * shows "days" (or "day" if singular).
 * All supported templates accept  to format numbers over 999 with commas.
 * All supported templates accept  to format numbers over 999 with commas.
 * Outstanding John, I'm finding no issues or errors. — Huntster (t @ c) 17:19, 10 June 2016 (UTC)
 * Thanks. It now supports  which I added to the documentation. Here are two examples using debug to make the sort key visible. The sort key is based on the number of days and fraction of a day.
 * I put the code in the main template and so am now using time interval rather than its sandbox. Johnuniq (talk) 01:00, 11 June 2016 (UTC)
 * Looks good for production use, many thanks! How should we go about replacing legacy age templates? Probably we should pick a few of the lesser-used ones first, and offer the replacement on the talk pages, pointing to this documentation, test cases and benefits of the switch. We can also start using time interval directly in infoboxes. — JFG talk 06:39, 21 June 2016 (UTC)
 * I've got a weakness for adding stuff which means it takes a long time to finish something like this. Yesterday I decided to work on checking that Module:Age and Module:Date could be updated from their sandboxes so time interval could be finished, and I could think about whether other templates might be migrated. I updated age in years, months and days/sandbox (and the testcases shows some differences between the current template and the new sandbox), but then I got sidetracked with two new features which I'll describe when they are finished. I should be ready to switch before the weekend, or definitely before next Monday. Johnuniq (talk) 07:27, 21 June 2016 (UTC)
 * See extract for some brief documentation on a new template; more later. Johnuniq (talk) 12:26, 21 June 2016 (UTC)
 * I've got a weakness for adding stuff which means it takes a long time to finish something like this. Yesterday I decided to work on checking that Module:Age and Module:Date could be updated from their sandboxes so time interval could be finished, and I could think about whether other templates might be migrated. I updated age in years, months and days/sandbox (and the testcases shows some differences between the current template and the new sandbox), but then I got sidetracked with two new features which I'll describe when they are finished. I should be ready to switch before the weekend, or definitely before next Monday. Johnuniq (talk) 07:27, 21 June 2016 (UTC)
 * See extract for some brief documentation on a new template; more later. Johnuniq (talk) 12:26, 21 June 2016 (UTC)

Partial dates
A new version is in the sandbox. I will be checking it over the next few days, but I think it implements everything discussed. The following illustrates "partial" dates which have only a year, or only a year and month. Any combination works: full/full, full/partial, partial/full, partial/partial.

A new option allows the possible range of years/months to be shown. @Huntster and JFG: You might like to try partial dates. Johnuniq (talk) 10:59, 15 June 2016 (UTC)


 * Very nice, not seeing any issues. — Huntster (t @ c) 18:30, 15 June 2016 (UTC)

Release
@JFG and Huntster: I changed time interval to use Module:Age rather than its sandbox and the template is ready for release. I'll try to update the documentation soon. Also of interest is extract which has got updated docs. I'm not sure about that name, but I wanted something short for testing Module:Date without the hassle of writing Lua code. Let me know about any problems! Johnuniq (talk) 01:32, 24 June 2016 (UTC)


 * Exciting!! You're awesome John, always coming up with great stuff. — Huntster (t @ c) 02:09, 24 June 2016 (UTC)


 * Good idea with the extract feature; I would suggest a more descriptive name such as parse date or read date. — JFG talk 09:12, 24 June 2016 (UTC)

Hours and minutes
I was wondering if any way could be made so that just hours and minutes were shown, which would be useful for very short duration early spaceflights typically measured in tens of hours rather than single digit days. For example, the Ranger program. Cheers! — Huntster (t @ c) 22:17, 23 July 2016 (UTC)
 * @Huntster: Is  enough? That shows hours/minutes, or days/hours/minutes if 24 hours or more.
 * Johnuniq (talk) 01:40, 24 July 2016 (UTC)
 * John, I was hoping to have just hm, so I could get something like 64 hours, 31 minutes, for example. Is there a technical issue preventing this? — Huntster (t @ c) 06:00, 24 July 2016 (UTC)
 * No problem, just had to add a bit of code to handle these. The template can now use  (hours only) or   (hours and minutes). Examples:
 * Johnuniq (talk) 04:00, 25 July 2016 (UTC)
 * John, you are awesome, I don't care what they say ;) — Huntster (t @ c) 05:18, 25 July 2016 (UTC)
 * Johnuniq (talk) 04:00, 25 July 2016 (UTC)
 * John, you are awesome, I don't care what they say ;) — Huntster (t @ c) 05:18, 25 July 2016 (UTC)
 * Johnuniq (talk) 04:00, 25 July 2016 (UTC)
 * John, you are awesome, I don't care what they say ;) — Huntster (t @ c) 05:18, 25 July 2016 (UTC)
 * Johnuniq (talk) 04:00, 25 July 2016 (UTC)
 * John, you are awesome, I don't care what they say ;) — Huntster (t @ c) 05:18, 25 July 2016 (UTC)
 * John, you are awesome, I don't care what they say ;) — Huntster (t @ c) 05:18, 25 July 2016 (UTC)

Seconds
, getting into very edge cases here, but can seconds be enabled? Several Apollo mission articles could support dhms. — Huntster (t @ c) 15:42, 11 October 2016 (UTC)
 * OK, I'll look at that. Probably won't do anything until next week. Johnuniq (talk) 00:47, 12 October 2016 (UTC)

@Huntster: I implemented dhms and hms. Examples: Give it a kick and let me know if any problems. Johnuniq (talk) 05:50, 15 October 2016 (UTC)


 * Thanks, fantastic as always. I'm enjoying implementing this template...put it to good use in the Boeing X-37, slowly rolling it out on other articles as I update infoboxen. — Huntster (t @ c) 05:54, 15 October 2016 (UTC)

Duration=on
, I'm trying to understand when this parameter should be used, but my brain isn't wrapping around the issue. If I'm counting the exact hours/minutes/seconds of a space flight, either in progress or ended, should I use duration=on or not? — Huntster (t @ c) 09:10, 29 May 2017 (UTC)
 * Probably not. This only makes sense at day granularity. Spaceflights already have hours and minutes, so we can either say a flight lasted 24 days, 9 hours and 18 minutes (it ended a few hours into its 25th day), or we can loosely say that it lasted 25 days (with duration=on). — JFG talk 09:55, 29 May 2017 (UTC)
 * JFG is right. To illustrate the idea of duration, suppose a baby was born at 9:00 am on Monday 1 May 2017. At 5:00 pm Friday 5 May 2017, the baby had an age of 4 days 8 hours, or just 4 days if measured in days. However, if a conference started at 9:00 am on Monday and finished at 5:00 pm the next Friday, we would say it had a duration of 5 days.
 * Using  adds a day because it includes the finishing day in the period. Johnuniq (talk) 11:13, 29 May 2017 (UTC)
 * Thanks to you both! Makes total sense. — Huntster (t @ c) 01:39, 1 June 2017 (UTC)
 * Using  adds a day because it includes the finishing day in the period. Johnuniq (talk) 11:13, 29 May 2017 (UTC)
 * Thanks to you both! Makes total sense. — Huntster (t @ c) 01:39, 1 June 2017 (UTC)
 * Thanks to you both! Makes total sense. — Huntster (t @ c) 01:39, 1 June 2017 (UTC)

Currently, the duration parameter adds a day to the interval, in order to display accurate durations over a period measured in days. However, if we want to display a duration measured in months or years, the template fails to add a month or a year to the raw interval. Case in point, in List of Falcon 9 and Falcon Heavy launches we say "Rockets from the Falcon 9 family have been launched 49 times over 7 years", although they have been launched from June 2010 to present, which is 8 years including 2017, and will be 9 years after June 2018. This situation jumped at me because the phrase is followed by graphs which show launch statistics with 9 bars for the years 2010 to 2018 inclusive. The code is. I think we should say "over 8 years" in this case, using the same reasoning as for days. When display granularity is months, we should add a month as well. what do you think? — JFG talk 10:28, 12 February 2018 (UTC)
 * I think this should work:
 * Johnuniq (talk) 22:06, 12 February 2018 (UTC)
 * It works, but for the wrong reason, because today is just a bit more than 7.5 years after the first flight. If we use e.g. October 2010 as a start date, we get 7 years with rounding ( → ), which is not the expected "duration" behaviour. — JFG talk 22:53, 12 February 2018 (UTC)
 * The concept of duration is well defined only when two full dates are involved and the duration is wanted in days. Consider:
 * Currently,  in both of the above examples includes the final day. What would you want it to do instead? No convention would regard 2 years as the correct result for the second case. Johnuniq (talk) 04:27, 13 February 2018 (UTC)
 * Currently,  in both of the above examples includes the final day. What would you want it to do instead? No convention would regard 2 years as the correct result for the second case. Johnuniq (talk) 04:27, 13 February 2018 (UTC)
 * Currently,  in both of the above examples includes the final day. What would you want it to do instead? No convention would regard 2 years as the correct result for the second case. Johnuniq (talk) 04:27, 13 February 2018 (UTC)
 * Currently,  in both of the above examples includes the final day. What would you want it to do instead? No convention would regard 2 years as the correct result for the second case. Johnuniq (talk) 04:27, 13 February 2018 (UTC)

Sorting issue
Please take a look at Template_Talk:Time interval/sandbox1, where I copied a table from List of European supercentenarians exhibiting a sorting problem. Click on the "Age" column to sort by increasing age, and look at the lines for Venere Pizzinato-Papo and Magdalena Oliver Gabarro. Pizzinato is listed with 114 years, 252 days, and Gabarro with 114 years, 251 days, but Gabarro is sorted as older. The error must be linked to the comparison between a time interval between fixed dates (for a dead person) and a time interval between an old date and today (for a living person). I have displayed the sort keys in debug mode to help understand what happened. Even the sort keys for full days seem to be off by one when the person's birth date is prior to 1900. — JFG talk 00:34, 9 July 2018 (UTC)
 * Interesting! The issue is due to an ugly fact about reporting dates in years/days. This is a summary:


 * 1896-11-23|2011-08-02| → 41,889 days → 114 years, 252 days
 * 1903-10-31|2018-07-09| → 41,890 days → 114 years, 251 days
 * The first of the above is a smaller number of days and so has a smaller sort key. That means it sorts before the second result.
 * The problem is that the first is reported as a larger number of years/days. I'll need a bit more time to remind myself why that can happen, but following is an external check.
 * http://www.timeanddate.com/date/durationresult.html?y1=1896&m1=11&d1=23&y2=2011&m2=8&d2=2
 * From and including: Monday, 23 November 1896
 * To, but not including Tuesday, 2 August 2011
 * It is 41,889 days from the start date to the end date, but not including the end date
 * Or 114 years, 8 months, 10 days excluding the end date
 * http://www.timeanddate.com/date/durationresult.html?y1=1903&m1=10&d1=31&y2=2018&m2=7&d2=9
 * From and including: Saturday, 31 October 1903
 * To, but not including Monday, 9 July 2018
 * It is 41,890 days from the start date to the end date, but not including the end date
 * Or 114 years, 8 months, 9 days excluding the end date
 * Warning:
 * Larger time units are added before smaller time units. As months vary in length, the number of days shown in the years/months/days breakdown may remain the same even if a different start or end date is entered.
 * Note that the second result is has a larger number of days but a smaller years/months/days result. Also, there is a warning.
 * I'll try to do more thinking later but handling it in a reasonable manner might be difficult. Johnuniq (talk) 05:13, 9 July 2018 (UTC)
 * OK, I've got the answer, but you're not going to like it. The leap years in question are:
 * 1904, 1908, ... 2008, 2012, 2016
 * The first result includes from 1904 to 2008 inclusive.
 * The second result includes from 1904 to 2016 inclusive.
 * Therefore the second result spans two more leap years. It is reported with a smaller number of days because two of its years are longer. Johnuniq (talk) 05:25, 9 July 2018 (UTC)
 * We came to the same conclusion. The root cause is that "114 years" does not represent a fixed number of days; it varies depending on where we start in the leap year cycle. This explains why I noticed discrepancies when the start date is before/after 1900, as that year was exceptionally non-leap. For the person born in 1896, 114 years include 27 leap years (total 365 × 114 + 27 = 41,637 days), whereas for the person born in 1903, 114 years include 29 leaps (yes, 1904 and 2016 included, total 365 × 114 + 29 = 41,639 days). We can't expect year+days counts to be sorted the same as pure day counts. Will be fun to explain to our gerontologist friends, who are used to sorting people based on "years and days alive"… — JFG talk 05:33, 9 July 2018 (UTC)
 * The second result includes from 1904 to 2016 inclusive.
 * Therefore the second result spans two more leap years. It is reported with a smaller number of days because two of its years are longer. Johnuniq (talk) 05:25, 9 July 2018 (UTC)
 * We came to the same conclusion. The root cause is that "114 years" does not represent a fixed number of days; it varies depending on where we start in the leap year cycle. This explains why I noticed discrepancies when the start date is before/after 1900, as that year was exceptionally non-leap. For the person born in 1896, 114 years include 27 leap years (total 365 × 114 + 27 = 41,637 days), whereas for the person born in 1903, 114 years include 29 leaps (yes, 1904 and 2016 included, total 365 × 114 + 29 = 41,639 days). We can't expect year+days counts to be sorted the same as pure day counts. Will be fun to explain to our gerontologist friends, who are used to sorting people based on "years and days alive"… — JFG talk 05:33, 9 July 2018 (UTC)

Prefix option
Would it be possible to add a prefix option, to display something before the calculated time interval? That would allow handling situations such as "over 3 months", "about 3 to 4 months", or "~4m", without messing up the sorting. Same rationale as with nts. — JFG talk 23:26, 9 October 2018 (UTC)
 * Yes, I'll ping you in a day or two when done. It's a little more complicated than just this template because Module:Age handles several things but it will be do-able. Johnuniq (talk) 04:05, 10 October 2018 (UTC)
 * @JFG: I'm wondering whether to insert a space. The simplest for me and possibly users would be to insert exactly what is given in the  parameter. That means "prefix=~" (no space) would give "~3 months" (no space after "~"), and "prefix=over " (with space) would give "over 3 months" (with space). Also, &amp;nbsp; could be used instead of a space if wanted. However, templates with spaces are a little ugly and might be refactored by wikignomes. Or, the module could attempt to guess whether a space should be inserted, so "prefix=over" (no space) would give the same result as before. What do you think? Johnuniq (talk) 06:33, 10 October 2018 (UTC)
 * Let's keep it simple: insert exactly what the user specifies. Do explain in the documentation and in an example that if a space is required, the user should use . Still, I'm curious about your "guessing" option. What do you envision as the heuristic to decide whether to insert a space? — JFG talk 09:29, 10 October 2018 (UTC)
 * Convert has some quite complex mumbo-jumbo for a couple of options that allow users to insert text. A brief example is that if the text is "+" convert won't insert a space (5+ feet) but it mostly will otherwise. I would prefer to avoid that as it is too hard for anyone to follow. Johnuniq (talk) 09:43, 10 October 2018 (UTC)
 * Agreed. Keep it simple. — JFG talk 14:19, 10 October 2018 (UTC)

@JFG: I've had another case of brain failure. In a template, named parameters are trimmed by MediaWiki so " " (with a trailing space) was never going to work because the template actually receives "over" (no space) as the parameter. That might be why convert mucks around trying to automatically add spaces except when they are not wanted. The workaround is to require users to enter " " (32 = space) or " " but that is super ugly. Another ugly solution would be to always append a space after the  text but also provide a parameter   which adds nothing. Any thoughts? Johnuniq (talk) 09:46, 11 October 2018 (UTC)
 * Perhaps we can a heuristic that's both simple and "clever": add a space except when the prefix is just one character. So that over yields "over 3 months" while ~ yields "~3 months". — JFG talk 10:01, 11 October 2018 (UTC)

@JFG: Good idea—simple to implement and to understand. I have implemented this in the sandbox. Please try it out and if nothing arises I'll put in the main module. This accepts  to insert TEXT before the visible result but after any sort key. A space is added after TEXT if it is more than one Unicode character. Following are some examples using sortable=debug to display the normally hidden sort key. Johnuniq (talk) 06:37, 12 October 2018 (UTC)
 * Works beautifully. Let's put this in production. — JFG talk 10:08, 12 October 2018 (UTC)
 * OK, it's live. Johnuniq (talk) 10:20, 12 October 2018 (UTC)
 * Thanks. First using it on List of Falcon 9 first-stage boosters, look at the second line of the B1047 entry. — JFG talk 13:24, 12 October 2018 (UTC)

Minutes and seconds
Hi, I was wondering if it would be possible to allow simple minutes or seconds to be shown, as in M and s. For example, to allow mission durations to be shown in those single units. If it is a lot of work, then don't worry about it, but I can see where it might be useful for very short events. Thanks! — Huntster (t @ c) 09:25, 28 July 2020 (UTC)
 * I can look at this. As you would know, the show=x parameter accepts hm and hms. Are you saying there is a use case where you would want to display, for example, 92 minutes rather than 1 hour 32 minutes? If minutes are only below 60, show=hm can be used. Similarly, show=hms would work if seconds < 60. No need to go into detail, I just want confirmation of what is needed before thinking about it. Johnuniq (talk) 07:25, 29 July 2020 (UTC)


 * , this came up after I was touching up TDRS-B, which was lost in the Challenger accident. I wanted to show a simple 73 seconds (destruction after launch), rather than 1 minute, 13 seconds. While I don't strictly have a use-case for minutes at the moment, I figured the implementation of both seconds and minutes would be fairly similar, and would give end-users additional options. Like I said, if this is unreasonably complicated, don't worry about it as it isn't something I critically need. Just thought it might be useful. — Huntster (t @ c) 08:45, 29 July 2020 (UTC)

I've put the code in the sandbox. Please give it a try and let me know if there are any problems. Johnuniq (talk) 09:45, 2 August 2020 (UTC)
 * , simply outstanding. Been testing it with all sorts of combinations and haven't noticed any issues at all. Thanks so much for working on this. It makes the template all-around flexible now. — Huntster (t @ c) 10:37, 2 August 2020 (UTC)
 * OK, I'll take it live in under 24 hours. Johnuniq (talk) 10:47, 2 August 2020 (UTC)
 * It's live in the main modules. Johnuniq (talk) 02:57, 3 August 2020 (UTC)

Subst heart
Re diff and : It doesn't worry me but naturally there was a reason with a practical effect. Consider: Johnuniq (talk) 23:59, 15 September 2020 (UTC)
 * I know, I know, but the unnamed parameter is the standard and I can only recall one other time where another parameter was used. I've never seen an non-demonstration use of the unnamed parameter so for all realistic calls there is no effect. --Trialpears (talk) 04:56, 16 September 2020 (UTC)

How often is "now" updated?
I'm looking at Voyager 2 in its infobox where the mission duration is specified. It has  which should be (as of a few minutes ago) 43 years, 2 months, 13 days, 20 hours, 53 minutes, 17 seconds. However it's displaying 43 years, 2 months, 11 days, 10 hours, 44 minutes (a little over two days less). And refreshing the page doesn't update the minutes and seconds.

I'm guessing something is preventing the default value, or "now", from being updated frequently. If it only updates every few days, maybe it should be discouraged to use minutes and seconds for situations when one of the parameters is default, and/or or have a footnote saying "as of X date/time" (when it was last updated), or put "approx." before it? -kotra (talk) 19:42, 3 November 2020 (UTC)
 * It's due to caching. I put an explanation here and it is at VPT. I don't have time to look up the parser time function at the moment but it would be easy to insert something that gives the current date (and time if wanted)—that "current" would match the age calculation since they would bother be updated together. Johnuniq (talk) 22:54, 3 November 2020 (UTC)
 * See #time at Help:Magic words and the details at mw:Help:Extension:ParserFunctions. Johnuniq (talk) 03:40, 4 November 2020 (UTC)

Could YYYY/MM/DD and YYYY/MM be supported?
JIPA / CUP use these date formats. The first only differs from ISO in using / instead of a hyphen, and so should be unambiguous. The second avoids the problem that *YYYY-MM has of looking like a range, and so should also be unambiguous.

Please ping me if I should request this elsewhere. — kwami (talk) 09:10, 11 August 2022 (UTC)
 * Decoding dates is done by Module:Date which rejects slashes due to conflicting interpretion of 1/2/22 as dmy or mdy. Format yyyy-mm-dd (or yyyy-m-d) is accepted as useful at Wikipedia and due to ISO 8601. In principle YYYY/MM/DD would work but a problem is that the module is used by many templates which really should not encourage input of weird formats. Full flexibility requires use of the #time parser function. Johnuniq (talk) 10:06, 11 August 2022 (UTC)
 * Okay, thanks. I'm sure they can accommodate. — kwami (talk) 10:09, 11 August 2022 (UTC)