Getting a ParserFunction error. See Template talk:User age. Also Template talk:Age is showing expression errors where I assume it did not previously. – wbm1058 (talk) 02:22, 31 March 2022 (UTC)[reply]

The module is fine. I replied at Template talk:User age to say that format=raw is needed (for example, {{age|format=raw|21 June 1984}}). That is documented at Template:Age. Template talk:Age is showing errors because of your edit at {{age/sandbox}} (no problem, but that's the reason). Johnuniq (talk) 03:57, 31 March 2022 (UTC)[reply]

OK, I reverted my sandbox edit, and updated Template:Age#TemplateData to include {{{format}}}. – wbm1058 (talk) 12:03, 31 March 2022 (UTC)[reply]

Thanks, template data is over my head. Johnuniq (talk) 23:02, 31 March 2022 (UTC)[reply]

So I noticed a few weeks ago that Template:2022 Russian invasion of Ukraine infobox's date section is ahead by a day. I left a query about it here but that user couldn't answer my question and directed me here instead. My questions remain the same: is this module based on an early time zone where the current date would be March 7 rather than March 6, the current date in Ukraine? And is there a way to fix that so the information displayed is accurate? Tagging @Johnuniq as the top editor here. QuietHere (talk) 14:54, 6 March 2023 (UTC)[reply]

Template:2022 Russian invasion of Ukraine infobox uses the following template. It should use the second example which is exactly the same but clearer.

• {{Age in years, months, weeks and days|day1=24|month1=2|year1=2022|day2=|month2=|year2=|duration=yes}} → 2 years, 10 months and 2 days
• {{Age in years, months, weeks and days|24 February 2022|duration=yes}} → 2 years, 10 months and 2 days

The template is based on UTC time, the same as that shown by recent changes or histories at Wikipedia. Your original question was written at 14:29, 24 February 2023 UTC and said that the template was showing "(1 year and 1 day)" instead of exactly one year. The reason it showed an extra day during 24 Feb 2023 is the duration=yes parameter. That tells the template to include the extra day. For example, a meeting starting at 9:00am on 23 Feb and finishing at 5:00pm on 24 Feb had a duration of two days. I would have to examine the code to remind myself how the template handles times but that is rather unimportant due to my next piece of news copied from my comment at Template talk:Age in years and days: The template gives the correct results at the time the page is "purged" (see WP:PURGE). Readers see a cached copy of the html to save the overhead of the server having to regenerate the page from the wikitext. The fix is edit the page then click publish without making any changes and with no edit summary. That updates template results. In the context of the problem you report, that is saying that the displayed years, months, weeks and days will not change until someone purges the template. Johnuniq (talk) 04:38, 7 March 2023 (UTC)[reply]

Tried a few different purge options but they haven't made a noticeable difference. QuietHere (talk) 12:22, 7 March 2023 (UTC)[reply]

I would need a link to the page in question (is it an article? the template?) and a copy/paste of the text that is wrong. You might add one thing that you tried to fix it. Which page did you edit then click publish? Template:Russian invasion of Ukraine (2022–present) infobox currently says "(1 year, 1 week and 6 days)" which looks correct. Johnuniq (talk) 06:51, 8 March 2023 (UTC)[reply]

The infobox exists solely as a template call on Russian invasion of Ukraine (2022–present) so the concern should be with the template page. But I've tried purges on both pages and neither changed anything. And no, by my count that's still a day ahead. The day we're starting with is Feb. 24 which was two weeks ago on Friday. As today is Wednesday, two days before Friday, that would make it five days since last Friday, March 3. I've even tried adding an end date and it still calculates one extra day than there should be no matter what day I enter. QuietHere (talk) 15:39, 8 March 2023 (UTC)[reply]

Here is the template from Thursday 24 February 2022 to Friday 10 March 2023, including the start and end dates (because duration=yes):

• {{Age in years, months, weeks and days|24 February 2022|10 March 2023|duration=yes}} → 1 year, 2 weeks and 1 day

It's from a Thursday to a Friday, inclusive, so there must be one day left over, as shown by the template. A reliable calculator doing the same calculation says:
From and including: Thursday, 24 February 2022
To and including: Friday, 10 March 2023
Result: 380 days
It is 380 days from the start date to the end date, end date included.
Or 1 year, 15 days including the end date.
Or 12 months, 15 days including the end date.
That agrees with the template. Johnuniq (talk) 02:25, 9 March 2023 (UTC)[reply]

Okay, now I've figured out where the confusion lies. February 24, 2022 was a Thursday as you said, whereas this year it was a Friday. I assumed that "one year" in this case would mean from Feb. 24 to Feb. 24 exactly, but in this case I guess it's going from one Thursday to the next and counting from there. Maybe? Or maybe it's something else like that. But this whole time, I'd been counting from Friday, Feb. 24, 2023, which is why my count was different by one. Now I'm not sure if that means that I'm wrong and the template has been right this whole time, but at least that's figured out. QuietHere (talk) 02:50, 9 March 2023 (UTC)[reply]

Although that could also mean absolutely nothing. It's not very clear to me. QuietHere (talk) 02:57, 9 March 2023 (UTC)[reply]

The calculation to get 1 year, 2 weeks and 1 day is like this:

• 24 Feb 2022 to 23 Feb 2023: 1 year exactly including the start and end dates
• 24 Feb 2023 to 9 March 2023: 2 weeks exactly including the start and end dates
• 10 March 2023: 1 day including the end date because duration=yes is used

Johnuniq (talk) 03:59, 9 March 2023 (UTC)[reply]

Oh, I see now. I just missed you using the word "inclusive" above. So it's intentionally designed to be inclusive? Should that not be changed, or is that preferred? QuietHere (talk) 04:26, 9 March 2023 (UTC)[reply]

I explained the theory of duration=yes above. The template is doing what it was told to do. Whether or not duration=yes should be used is something to be discussed at the talk page of Template:2022 Russian invasion of Ukraine infobox with a mention at one or two article talk pages where the template is used. If duration=yes is used, the template will be a bit misleading for the first few hours each day because the full day will be included. However, the template will be correct towards the end of the day because that day should be included. All that is a bit irrelevant because, as mentioned above, purging is needed to update the display. I would include it and forget about the purging issue except for important days such as the anniversary and hopefully there won't be many more of them. Johnuniq (talk) 06:25, 9 March 2023 (UTC)[reply]

It will be fine to have some examples in documentation. Thanks! A.sav (talk) 20:00, 17 November 2023 (UTC)[reply]

If you spell out what is wanted I might be able to provide advice. However, age_generic is not intended to be called by another module. It's purpose is given in the documentation at Module:Age. Johnuniq (talk) 05:48, 18 November 2023 (UTC)[reply]

I need {{age in years, months and days}} function in module. Thanks! A.sav (talk) 08:17, 18 November 2023 (UTC)[reply]

Simplest would be to expand the template like this:

local function main(frame)
	local date1 = '1 April 1980'
	local date2 = '20 July 1990'
	local result = frame:expandTemplate({title = 'age in years, months and days', args = {date1, date2}})
	-- result = '10 years, 3 months and 19 days'
end

Johnuniq (talk) 08:36, 18 November 2023 (UTC)[reply]

Thanks, but there are 200 such templates on page. It seems it will be too expensive to use such native implementation. A.sav (talk) 08:43, 18 November 2023 (UTC)[reply]

What page? What module? Module:Age just gathers the parameters (date1 and date2) and calls Module:Date to get the numbers (10, 3, 19 in above example), then inserts the years/months/days text. Another module could do that too. Or, you could call age_generic and pass something that looks like a frame sufficiently well to do what age_generic needs as can be seen by inspecting its code. Johnuniq (talk) 09:26, 18 November 2023 (UTC)[reply]

I want to localize no:Module:Liste over eldste personer for Bulgarian. I did it for Belorussian, Serbian and Romanian, and Russian localization is also based on my Belorussian localization. Well, I can even derive months/days calculation from bulgarian template implementation, but I want to reuse existed Age module. A.sav (talk) 13:12, 18 November 2023 (UTC)[reply]

Using abbr=on produces output like "1d 2h 3m 5s", which violates MOS:UNITS (see "expressing time durations"). The correct short format must have no-break spaces between numbers and units, and use "min" for minutes.

Namely, please add sep = ' ', and change m = 'm', to m = 'min', to abbr_on here. — Mikhail Ryazanov (talk) 05:10, 15 July 2024 (UTC)[reply]

The reason that modules such as this require advanced rights to edit is to reduce the churning that would occur from normal bold editing. The spacing has been the way it is for a very long time and more than a mention of a guideline is needed to effect a change. For example, there would need to be a reasonable attempt to work out where the abbr=on option is used and whether there are reasons for it being the way it is. Also, some wider discussion before a change would be required. Johnuniq (talk) 05:46, 15 July 2024 (UTC)[reply]

As the first paragraph of MOS:NUM says, "The aim is to promote clarity, cohesion, and consistency, and to make the encyclopedia easier and more intuitive to use", so it's not that "more than a mention of a guideline is needed" to ensure conformance, but quite the opposite – any deviation from the MOS must be justified. That particular part of MOS:NUM has existed in its current state since 2016, after this discussion, which you definitely should have seen (based on your participation in other topics on that page at that time) but not objected. Between 2014 and 2016, there was some inconsistency due to an accidental mistake; but as far as I can tell, minutes were always "min", not "m" (see MOS:NUM#Specific units), and the unspaced format was never considered acceptable. So it seems to me that abbr_on was introduced here without enough thought and apparently without discussing its consistency with WP:MOS or any external standard or style guide. The fact that nobody has complained yet doesn't mean that it should not be corrected. I personally didn't notice such use of this module in any articles I read or edit until very recently, in Boeing Starliner § List of spacecraft. — Mikhail Ryazanov (talk) 20:03, 15 July 2024 (UTC)[reply]

It sounds like you think I'm somehow responsible for the current situation. I wrote Module:Age but that was to emulate what the templates that it replaced did (without some errors), and to add some extras that others requested. I don't recall expressing an opinion on the spacing issue raised here. I think templates and modules should follow consensus from specific discussions. I have no idea where abbr=on is used but I do know that an effort should be made to work that out before making a change that conceivably could affect hundreds of articles. Guidelines are great but some thought about consequences should occur before changing how templates have worked for several years. Johnuniq (talk) 03:11, 16 July 2024 (UTC)[reply]

A quick look makes me think that abbr=on is only used in:

• {{age in days}} if |show unit=abbr is used
• {{time interval}} if |abbr=on is used

{{age for infant}} displays units but never like |abbr=on. I can't think of any other templates using Module:Age where a unit like d is shown. @JFG and Huntster: You are both away at the moment but on return you might like to offer an opinion on this request, or report where abbr=on has been used. Johnuniq (talk) 03:13, 16 July 2024 (UTC)[reply]

Johnuniq, there's noting personal – I'm addressing you about the current situation only because you are the one who introduced abbr_on but in that edit's summary did not explain why, neither can I find anything reasonable on this discussion page, nor the pages of the templates this option was supposed to reproduce. So you definitely know about the situation and its history much more that I do, thus I'm asking you why this has happened without any regard for WP:MOS. Since you're also much more familiar with the tools, it would help if you can find how much and where {{time interval}} with |abbr=on is used to assess how it will be affected by my proposed correction. (Regarding abbreviations in {{age for infant}}, it looks like an example of somebody's made-up nonsense: no explanations why standard notation can't be used for standard units, plus searching Google for infant age "dys" suggests that it's not even some established jargon in any field.) And yes, if Huntster and JFG can help, it would be appreciated, because I also didn't find any justification for the current behavior of "abbr" in their comments at Template talk:Time interval. — Mikhail Ryazanov (talk) 04:38, 16 July 2024 (UTC)[reply]

 Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. Okay, two things here. First, Mikhail, Johnuniq has indicated that they were not the one that decided what the module outputs, and I believe them. Their statement says that they simply took the existing templates and converted them to a module; if a template used "improper" abbreviations before the shift, they were ported into the module. Please don't put words into their mouths when they have sufficiently explained their role in the creation of this module.

Second, I am going to close this request until consensus can be determined. Let's not worry about why the module is the way it is, but whether it should be changed. For example, does it make sense to have different abbrevs for "infant" and "non-infant" statuses? Should this module be updated to better conform to the MOS? Primefac (talk) 12:24, 16 July 2024 (UTC)[reply]

Thanks for your considered words, Primefac. Regarding this issue, I no longer have skin in this game as I've mostly abandoned en.wiki, but that said I've never been one to treat MOS as gospel that must be rigidly adhered to. It is a guideline that editors can use to create a more uniform appearance for the project, but following it is not mandatory. If you think it should be, then get it promoted to policy. Now, non-breaking spaces are a fine change to make, and a good call to keep things from wrapping. However, I don't think that changing "m" to "min" here is good, since in most circumstances it should be obvious based on how and where it's being used. (As for {{Age for infant}}, what it prescribes is weird, but "days" doesn't seem to abbreviate in actual application, so who knows what's going on there.) — Huntster (t @ c) 16:06, 16 July 2024 (UTC)[reply]

@Primefac: The general consensus has been established in the MOS:NUM discussion I've linked above. From WP:CONLEVEL, it should prevail over any local consensus (which, regarding the current wrong format, wasn't really established anywhere). Moreover, almost all articles using |abbr=on found by Johnuniq (see below) are about astronomy or spaceflights, and their corresponding Wikipedia:WikiProject Astronomy/Manual of Style and Wikipedia:WikiProject Spaceflight/Style guide have also established consensus to "follow the main Manual of Style"/"conform to the Wikipedia:Manual of Style", only with some stricter requirements to use UTC, 24-hour time and SI units (in which "m" doesn't mean "minute"). If you think that some other consensus needs to be established or changed, please tell explicitly. (And please explain what exactly did you mean by "don't put words into their mouths" or apologize.) — Mikhail Ryazanov (talk) 04:43, 21 July 2024 (UTC)[reply]

I'll give a couple more days for feedback, but so far I am not seeing any significant opposition to the proposed update with the few comments that have come in the last few days. Primefac (talk) 12:09, 21 July 2024 (UTC)[reply]

If anyone wants to examine how abbr=on is used, see User:Johnuniq/sandbox (permalink) which shows 297 {{time interval}} in 77 articles. These are the only ones that used abbr=on in the all-articles dump from 1 July 2024. Johnuniq (talk) 00:53, 17 July 2024 (UTC)[reply]

Inspecting all occurrences of {{age in days}} shows that none use show unit=abbr. Similarly, none of {{age for infant}} use abbr=on. Johnuniq (talk) 02:20, 17 July 2024 (UTC)[reply]

I changed {{Time interval}} to use Module:Age/sandbox and edited the latter to add the separator for abbr=on. I don't have an opinion on the outcome but I've looked at a couple of articles from my list linked above and the space looks odd to me. Perhaps I'm just used to the extreme abbreviated version? At any rate, it would be good to get opinions from editors currently interested in affected articles rather than rely on a guideline that may or may not throw light on what should happen in these cases. An article which uses a lot of these is Uncrewed spaceflights to the International Space Station which currently has a mixture of fixed-text durations such as "13 days, 12 h, 35 min" contrasted with "84 d 7 h 52 m" from the template. Using "84 d 7 h 52 min" looks weird to me although even a tiny discussion somewhere showing support would help. Following is an example from that article showing durations without and with the space.

• 84d 7h 52m
• 84 d 7 h 52 m

If the mixture of days/h/min were wanted, something could be arranged. Johnuniq (talk) 07:11, 22 July 2024 (UTC)[reply]

The correct short format for these examples is "13 d 12 h 35 min" and "84 d 7 h 52 min" – using "min" for minutes, not mixing words with unit symbols, and without commas ("13 days, 12 h, 35 min" is a list of three different durations). An "extreme abbreviated version" would be "P13DT12H35M" and "P84DT7H52M", but it's not what we need here. — Mikhail Ryazanov (talk) 18:34, 22 July 2024 (UTC)[reply]

OK, Primefac and Johnuniq, since you haven't made any progress in the past week and apparently wanted some broader discussion, where do you want it to happen: WT:MOSDATE, WT:MOS, WP:VPPOL, or somewhere else? — Mikhail Ryazanov (talk) 01:25, 29 July 2024 (UTC)[reply]

There should be an attempt to get opinions from editors interested in the articles that would be affected by the proposed change. Given a few days for people to express an opinion, even a tiny amount of support would convince me. We are discussing what is essentially trivia because anyone capable of reading the articles where abbr=on is used would be able to work out what a duration of 2h 34m meant, and writing 2 h 34 min instead would only be done to satisfy those with an itch. I don't care what people want, so long as content builders have a say. Johnuniq (talk) 03:09, 29 July 2024 (UTC)[reply]

"Would be able to work out" is not a valid argument. For example, everybody can understand "illogical punctuation", but MOS:LQ requires using the "logical" one for consistency. And let me remind again about WP:CONLEVEL, that few editors of particular articles cannot override the general rules (especially when they've already explicitly agreed to follow WP:MOS); if they want to, the exceptions must be discussed at WT:MOS (or its relevant subpage). So where exactly do you want to get the opinions? — Mikhail Ryazanov (talk) 03:34, 29 July 2024 (UTC)[reply]

I've asked for clarification at Wikipedia:Village pump (policy)#Templates and WP:MOS. — Mikhail Ryazanov (talk) 00:39, 1 August 2024 (UTC)[reply]

(came from village pump) I'm not someone involved with the relevant articles, but I do agree that "13 d 12 h 35 min" looks very odd, "13d 12h 35m" is (to me) more natural (due to the consistent abbreviations) and easier to read. The latter point is because the extra spaces break up the content into 6 separate chunks rather than the intended 3 and so I have actively work to associate the abbreviation with the number. This is even worse when there are single-digit values "4 d 6 h 3 m" is bordering on gobledook while "4d 6h 3m" is coherent and understandable at a glance. I can understand a preference for "min" over "m" when used in isolation (e.g. "16m" is less clear than "16 min") but when used with hours and/or seconds the extra two letters add nothing. Thryduulf (talk) 01:03, 1 August 2024 (UTC)[reply]

Same here. And I agree. In this kind of complex abbreviation, the MOS guidelines might not lead to the best solution. It might be good to document at the MOS an acceptable alternative style for such multi-part integer-based quantities; they don't necessarily need to be done the same way as typical values and units (e.g. 3.6 V). Dicklyon (talk) 04:38, 1 August 2024 (UTC)[reply]

Reviewing the table with the mixed-units example in the MOS, I see that time duration is the only 3-part mixed unit case they talk about, and the example "1 h 30 min 7 s" just looks odd, compared to most of the others (but not as odd as the two-part "1 US fl pt 8 US fl oz", which I hope we never see anywhere). So, instead of asking here, I'd say take it up at MOS, and see if you can get "1h 30m 7s" approved as an OK alternative, especially given that such forms may be in wide use already. Dicklyon (talk) 04:55, 1 August 2024 (UTC)[reply]

I saw the note at the village pump. Johnbod's example:

• 84d 7h 52m
• 84 d 7 h 52 m

is the the key bit of information for me. The first is better because I can figure out what it means at a glance. The one with the spaces looks like someone's notes for a Bingo (American version) game. I'm sure that either would make sense in context, and I'm sure I could figure it out, but the first is more obvious.

Also, if this is getting used in infoboxes or data tables, then the very small savings in the width might be wanted. WhatamIdoing (talk) 03:23, 3 August 2024 (UTC)[reply]

There are two issues here: spaces or no spaces between numbers and abbreviations, and whether the abbreviation for minute(s) should be "m" or "min". On the latter question, the longer abbreviation is asserted to be required due to ambiguity with "month", however in practice that only exists when it it appears alone - when accompanied by any other unit of time (hours, seconds, days, years) both are unambiguous due to context. Thryduulf (talk) 10:07, 3 August 2024 (UTC)[reply]

Although I'm a bit late to the party, I fully agree with remarks by Johnuniq, WhatamIdoing, Thryduulf, Dicklyon and Huntster. The abbreviated format "15d 8h 34m" is more legible than the MOS-derived "15 d 8 h 34 min", especially in the context of long lists of spaceflights or other events. Let's keep this "exception" the rule here. — JFG ^talk 04:34, 10 September 2024 (UTC)[reply]