Wikipedia talk:Manual of Style/Dates and numbers

Question about MOS:TIME

MOS:TIME encourages us to use 2:30{{nbsp}}p.m.. Would we also use {{nbsp}} for 2 p.m.? Whatever the answer, could it be added to MOS:TIME? Thanks! GoingBatty (talk) 23:08, 8 February 2025 (UTC)

It seems facially unacceptable for a passage to have "2" and "p.m." broken up across successive lines. Remsense ‥ 论 23:11, 8 February 2025 (UTC)

To me, 2 p.m. seems too informal for an encyclopedia. I would require 2:00 p.m. --User:Khajidha (talk) (contributions) 23:38, 8 February 2025 (UTC)

To me, that potentially implies precision when it's not required to do so. I think it's perfectly fine in some contexts to state round figures without an "estimated" or "approximately", but why exclude the less precise form as an option? I have no real sense why it would be "informal"—that would seem vaguely akin to copyeditors mechanistically replacing "called” with "referred to as" or "bigger" with "larger" as if simple expressions are inherently less formal. Remsense ‥ 论 23:46, 8 February 2025 (UTC)

And I definitely find "bigger" to be too informal for encyclopedic writing. --User:Khajidha (talk) (contributions) 00:08, 9 February 2025 (UTC)

I don't think there's any real lexical or usage evidence for that position, but I understand the impulse.

[Sidebar: I had assumed big was longstanding Germanic vocabulary, but apparently it's shifted from meaning 'powerful' more recently, and great is (of course) the Old English term that would generally be used with the sense of 'large'.] Remsense ‥ 论 00:09, 9 February 2025 (UTC)

MOS:TIME says that 12 hour times should have a non-breaking space before the am or pm. It doesn't give an hour-only example in that paragraph but neither does it qualify it in anyway - so non-breaking spaces should always be used (I'd be tempted to use {{nowrap|2 p.m.}}).

It does give an example of 11 a.m. - so that implicitly says that 2 p.m. is perfectly valid.  Stepho  talk  02:12, 9 February 2025 (UTC)

Unregistered units not allowed to edit articles?

Just wondering why standard units are not allowed to be added to articles by unregistered users? I added the predominant units used in the Anglosphere. On English language Wikipedia. As WP:UNITS indeed appears to allow. 142.120.196.175 (talk) 21:33, 12 February 2025 (UTC)

It has nothing to do with being unregistered. Your edits would have been reverted regardless. They added imperial units to non-US-related articles, which is not "the predominant units used in the Anglosphere" and not encouraged by MOS:UNITS. —David Eppstein (talk) 21:50, 12 February 2025 (UTC)

On the contrary. MOS:CONVERSIONS directs users to include conversions in brackets after the main unit on most articles, and that's what the IP was doing. The issue with the IP's edits were that the customary units were generally not properly formatted, and they would have been better off doing the job using {{convert}}. Kahastok talk 18:55, 13 February 2025 (UTC)

Some of them were ... strange (example). --Redrose64 🌹 (talk) 18:04, 14 February 2025 (UTC)

RfC on film gauge styling

Film gauge is a measure of the width of photo and movie films, and is written as the width of the film in millimeters followed by the unit “mm”. Film gauges can be written either with a space (35 mm film), without a space (35mm film), or with a hyphen (35-mm film).

In the context of film gauges, should Wikipedia:

1. always use a non-breaking space (35 mm film)
2. always use no space (35mm film)
3. always use a hyphen (35-mm film)
4. let editors use their own judgement

and...

Should a statement specifying which style to use be added to MOS:NUM under the Specific units section, and/or to MOS:FILM under the Guidelines for related topics section? ~ Nikoledood (talk) 12:28, 22 February 2025 (UTC)

Background

I decided to make this RfC because I noticed that there was a lot of inconsistent styling in Wikipedia when it comes to film gauges. This RfC started from a discussion that I started on the talk page of MOS:FILM (Link to the discussion: 16 mm vs 16mm film). This topic has previously been discussed in 2019 on the talk page of the 35 mm movie film article, which reached a consensus to use a space between “35” and “mm” (Links to the discussion: Rfc: 35mm articles, Requested move 28 April 2019). This topic was also discussed in 2006 on the talk page of MOS:NUM, with no clear consensus (Link to the discussion: Questioning space before unit). Below is a summary of the main arguments from these discussions:

A space should always be used for film gauges because:

• It follows MOS:UNITSYMBOLS.
• It follows SI style conventions (SI Brochure, section 5.4.3).
• It is already the most common practice on Wikipedia. A space is used over 80% of the time.
• It is consistent with previous consensus.

A space should not always be used for film gauges because:

• Outside of Wikipedia, a space is usually not used, even by some film manufacturers. This makes it a common name under the WP:COMMONNAME policy.
• Using a space can make some sentences ambiguous and harder to read, whereas omitting a space or using a hyphen is always unambiguous.
• “00mm film” is a colloquial name for a type of film, and is therefore not subject to style conventions about measurements.

Taking the above points into consideration I believe that a space should always be used for film gauges. I also think that a statement that specifies this should be added to MOS:NUM under the Specific units section, and to MOS:FILM under the Guidelines for related topics section. Even though adding this statement to the MOS could be considered redundant since this styling issue already falls under MOS:UNITSYMBOLS, I feel like it needs a special mention because many editors believe that a space should never be used for film gauges, and because the non-use of a space is so common. ~ Nikoledood (talk) 13:04, 22 February 2025 (UTC)

Responses

I want to elaborate on the SI Brochure liked above. It states

Even when the value of a quantity is used as an adjective, a space is left between the numerical value and the unit symbol. Only when the name of the unit is spelled out would the ordinary rules of grammar apply, so that in English a hyphen would be used to separate the number from the unit.

So I favor using "35 mm film" based on the quoted paragraph, plus the fact that MOS:UNITSYMBOLS states

Exception: Certain units are generally represented by their symbols (e.g. °C rather than degrees Celsius) even on first use...

I believe film sizes are such a use. Jc3s5h (talk) 15:37, 22 February 2025 (UTC)

---

I would like to add a bit more background:

• MOS:UNITSYMBOLS specifically addresses the case where a value and a unit are combined into a compound adjective:

To form a value and a unit name into a compound adjective use a hyphen or hyphens... but a non-breaking space (never hyphen) separates a value and unit symbol.

• MOS:HYPHEN also addresses this use case, and says basically the same:

Values and units used as compound modifiers are hyphenated only where the unit is given as a whole word; when using the unit symbol, separate it from the number with a non-breaking space ( ).

The both say the same: write either 35-millimeter film or 35 mm film. — Edgar.bonet (talk) 10:29, 24 February 2025 (UTC)

Yeah, and the latter (35 mm film) seems indeed the logical spelling for Wikipedia. Gawaon (talk) 11:26, 24 February 2025 (UTC)

• Having read the above, I think it's clear that we should use a space (option A). The arguments for the unspaced version are fairly weak. However, I don't think we need to explicitly state this in the MOS, since it's a niche application of existing guidelines (UNITSYMBOLS). The "common name" argument is the strongest in favor of the unspaced version, with Ngrams [1] giving a ratio of 2:1 unspaced to spaced, but for me that isn't a huge enough difference to override our other guidelines and scientific practice. Toadspike [Talk] 14:27, 8 March 2025 (UTC)

• Option D - per MOS:VAR - when you have more than one acceptable style, and an acceptable style has already been established at an article, then leave it alone, we shouldn't be forcing changes with a hard and fast rule. When I started to search Google for 35 mm film, Google prompted me with: Did you mean: 35mm film? So I abandoned Google, and did some advanced searches through the Wikipedia Library, and surprisingly found an overwhelming preference for 35mm film with 25,775 hits, and only 8,114 for 35 mm film. Isaidnoway (talk) 15:19, 18 March 2025 (UTC)
• E MOSNUM should include a note that names / proper nouns that include units, such as names of calibres, ammunition and film gauges, are outside MOSNUM's scope. NebY (talk) 12:49, 19 March 2025 (UTC)

Discussion

This sounds a bit like the occasional dispute over at milhist concerning gun calibres (e.g. Category:Pistol and rifle cartridges many of which are unspaced). --Redrose64 🌹 (talk) 14:36, 22 February 2025 (UTC)

Indeed, and such a question was raised here last year at Wikipedia talk:Manual of Style/Dates and numbers/Archive 163#Ammunition calibre/length naming conventions. We didn't stretch MOSNUM to cover that either. NebY (talk) 13:00, 19 March 2025 (UTC)

Exactly. Though these names are derived from characteristic measurements, they are not actually measurements but names, and MOS:UNITS doesn't actually apply. oknazevad (talk) 14:29, 19 March 2025 (UTC)

Time zone and date only

In a discussion of the proper functioning of {{Start date}} the question came up of whether it is acceptable to use a time zone with just a date. For example, is 1 January 2025 (UTC) acceptable? I think it is acceptable and useful.

A related question: if one wanted to represent 1 January 2025 (UTC) in ISO 8601 notation, is this possible? In the past, I couldn't find anything in the standard clearly saying 2025-01-01TZ is wrong, nor can I find a statement that it is right. But today, in a version of ISO 8601 titled BS ISO 8601-1:2019 where BS stands for British Standard, I found an example buried in a section about something else, 5.5.1 Means of specifying time intervals. The example is

EXAMPLE 2 '2018-01-15+05:00/2018-02-20' is equivalent to '2018-01-15+05:00/2018-02-20+05:00' as the '+05:00' time shift also applies to the expression after the separator.

This demonstrates that the time zone (5 hours ahead of UTC in this case) may be used with just a date, the time of day being absent.

Jc3s5h (talk) 16:28, 5 March 2025 (UTC)

Certainly, writing "1 January 2025 (UTC)" is acceptable (to me) and useful (to all). Dondervogel 2 (talk) 20:12, 5 March 2025 (UTC)

Why? 1 January 2025 is the same date in all timezones, despite starting a few hours earlier in some than in others. Gawaon (talk) 20:22, 5 March 2025 (UTC)

Your reasoning makes no sense. To see this, try it out with a shorter time period. Would you defend the statement "The hour between 13:00 and 14:00 is the same hour of the day in all timezones, despite starting a few hours earlier in some than in others"? Dondervogel 2 (talk) 21:02, 5 March 2025 (UTC)

If a newspaper describes an event as occurring on March 5, 2025, in Washington DC, we know it occurred between 0000 hours March 5, 2025, and 0000 hours March 5, 2025, Eastern Standard Time (EST). We could describe it as March 5, 2025, EST. We know it couldn't have happened at 0100 hours March 5, 2025, Pacific Standard Time. Jc3s5h (talk) 22:18, 5 March 2025 (UTC)

Auto format dates in non-CS1 templates

I brought this up at Wikipedia:Village_pump_(technical)/Archive_218#Auto_format_dates_in_non-CS1_templates:

The Citation Style 1 (CS1) templates will automatically format dates on a page that invokes {{use dmy dates}} or {{use mdy dates}}. This works for all of the most common citation templates, but there are {{cite xxx}} templates that are not related and do nothing to dates, like {{cite patent}}, {{cite court}}, {{cite comic}}, and so on. Would it be a good idea and would there be interest in working out a standard way to auto-format dates for those unrelated wikitext citation templates?

A more experienced and skilled editor offered a technically better solution than what I initially floated. There wasn't much input on the should we do this aspect. I've held off on implementing this on the template where it was initially requested. Rjjⁱⁱⁱ (talk) 18:38, 22 March 2025 (UTC)

Since it appears that no-one cares enough to object, perhaps you should just do it.

—Trappist the monk (talk) 15:45, 28 March 2025 (UTC)

Agreed - just do it.  Stepho  talk  00:33, 29 March 2025 (UTC)

Thanks, and yes. I can make the change at {{cite comic}} first where the issue was raised and update the documentation. Just being cautious. Trappist the monk, do you want to move your sandbox module to regular module location? Rjjⁱⁱⁱ (talk) 06:12, 29 March 2025 (UTC)

Tweaked and moved to Module:auto date formatter. There is rudimentary documentation.

—Trappist the monk (talk) 15:24, 29 March 2025 (UTC)

Thanks! There was a bug for pages that had no date-formatting template, and I did a small fix; you may want to double-check me. Cite comic and its documentation are updated. I'm going to try and write an explanation/guide for Module:Auto date formatter/doc explaining how to add it to a template, but also to point editors towards doing specific-source template if possible. Rjjⁱⁱⁱ (talk) 20:53, 29 March 2025 (UTC)

Tmcft

In Srisailam Dam I just came across the use of Tmcft as a volume unit throughout the article. {{Convert}}'s documentation doesn't say it supports Tmcft. Both this MoS style page and the convert template are UK/US orientated, but this unit is apparently used in India so sources from there probably use it. Commander Keane (talk) 01:51, 23 March 2025 (UTC)

Thank you for pointing this out. What a bizarre unit. I replaced it with billion cubic feet so at least Americans can understand it. For the rest of the world it still needs converting to something more user friendly (maybe km^3?). Dondervogel 2 (talk) 09:38, 23 March 2025 (UTC)

That's not a solution (and your edits on the article should be reverted). The unit may seem bizarre at first sight, but it's used all the time in WP:RS about Indian dams (random example: [2]), so we have to use it in our articles about such dams as well. And when you look at this list of volume units, the unit won't seem so bizarre anymore. :-) Commander Keane, I don't know much about {{Convert}}, but the intro here says "Units should be discussed at Template talk:Convert". I guess that's what you want to do. I think it would make perfect sense to add an entry for this unit, and if I understand that list of volume units correctly, the required change is very simple: just add a line mapping "tmcft" to "=e9cuft". — Chrisahn (talk) 10:30, 23 March 2025 (UTC)

I strongly disagree. We have enough units in circulation. This one has zero benefit. If there are other articles that use tcmft, they should all be given the same treatment. Dondervogel 2 (talk) 10:50, 23 March 2025 (UTC)

Articles about dams in India should use the same unit as almost all WP:RS about dams in India, and that unit is tmcft. This is the English Wikipedia, not the American Wikipedia. There are over 200 million English speakers in India. Not much less than in the US, and several times more than in the UK. There are different variants of English, and different systems of units. We use country-specific units in articles about American or British topics, so of course we also use country-specific units in articles about Indian topics. — Chrisahn (talk) 11:00, 23 March 2025 (UTC)

P.S. Once {{convert}} can handle tmcft, the unit will become much less bizarre because we can convert it to km³ (or whatever is appropriate in a given context). (Imperial units in general are rather bizarre. Cubic feet mean nothing to me, never mind the factor of a thousand million or billion...) — Chrisahn (talk) 11:15, 23 March 2025 (UTC)

Actually it's not a unit at all, but (as the article about it correctly says) just as abbreviation. "km" and "kilometres" are not two different units, but one is the abbreviation of the other. So is "tmcft", if a fairly bizarre one (why not "bcft"?). Should this specific abbreviation be useful in certain cases, I'd suggest to introduce it in parentheses after the spelled-out form, as is customary for not universally known abbreviations: Its capacity is 178 billion cubic feet (tmcft). Plus it should certainly be converted into metric units too, like Dondervogel 2 pointed out. There can be no excuse not to convert – like we also convert miles into kilometres (in parentheses) in articles referring to the US. "It's the local custom, so nobody outside the country needs to understand it" is not a good rationale. Wikipedia is meant for a worldwide audience and should be understandable to anybody who speaks English, regardless of the variety one is accustomed to. Gawaon (talk) 11:12, 23 March 2025 (UTC)

I agree, it definitely should be converted using {{convert}}. But since all WP:RS about Indian dams use this abbreviation, it would be confusing for readers and editors to use e.g. "billion cubic feet" instead. I think the convention for not generally known units is to link them to their article, in this case tmcft. – Regarding the question, "why not billion": Probably because of the fairly bizarre mess with long and short scales. It's simply not always clear what "billion" means. — Chrisahn (talk) 11:26, 23 March 2025 (UTC)

Similar case: Our articles about horse racing use the bizarre unit furlong (without an explanation, except maybe a link to furlong), because that's what all the sources use. See e.g. Secretariat (horse), Northern Dancer, etc. We don't say, "that's bizarre, we'll replace that by km or miles". We do what the sources do. Anything else would be confusing for our readers and our editors. — Chrisahn (talk) 15:52, 23 March 2025 (UTC)

We do not do what the sources do; our articles would be an awful jumble if we did. MOS:UNIT describes what we do. When specifying capacity in cubic metres, we might provide a parenthetical conversion to cubic feet, but that should use a notation that general readers both in and outside India can understand. NebY (talk) 20:06, 23 March 2025 (UTC)

By that logic, we should specify the distances in articles like Secretariat (horse) in kilometers, and maybe provide a parenthetical conversion to miles, so that general readers both in and outside horse racing can understand. — Chrisahn (talk) 20:21, 23 March 2025 (UTC)

We certainly should convert them into kilometres too. If we don't yet, that's a shortcoming that'll hopefully be fixed sooner or later. We're writing for a general audience, not just the specialists, so even if the specialists in any given area use some specialized unit nobody else is using (whether furlongs or tmcft or anything else), it's our job to convert them into more accessible units. The RS might not to that because they aren't written for a general audience. Nevertheless, it remains our job to rectify that. Even in India, while the dam builders might know what a tmcft is, I suspect if you ask a random person on the street they won't be able to tell you much about it. Gawaon (talk) 22:19, 23 March 2025 (UTC)

Horse racing: Yes, we should {{convert}} furlongs, but telling editors to replace all occurrences of "furlong" in Secretariat (horse)#Racing statistics by some other unit would be disruptive rather than useful. In the same vein, we shouldn't require editors to replace tmcft in articles about Indian dams. We should enable them to {{convert}} it.

Regarding "random person on the street" – People who have read about such a topic will know the unit, and they'll at least understand the numbers in relation. Example quote: "...permitted Goa to use 24 tmcft (excluding the 9.395 tmcft prevailing uses), Karnataka to use 5.4 tmcft (including 3.9 tmcft for export outside the basin) and Maharashtra to use 1.33 tmcft..." That's close to what the sources write. Using a different unit would only confuse a "random person on the street".

Articles about US dams use the even more bizarre unit "acre•foot". A "random person on the street" won't be able to tell you much about that unit, yet we're fine with it. If we let Americans use their bizarre units, we should let Indians use theirs as well. — Chrisahn (talk) 02:29, 24 March 2025 (UTC)

Sure, we can let them use their bizarre units, just as long as we convert them too. I'm all for using the convert template for that purpose, I don't say we should omit the originally specified units. Gawaon (talk) 17:41, 25 March 2025 (UTC)

Even so, I'm now curious how many furlongs per fortnight the speed of light actually is. We should certainly use that time-honoured unit more often! Gawaon (talk) 22:34, 23 March 2025 (UTC)

1802617499785.3. --Redrose64 🌹 (talk) 23:24, 23 March 2025 (UTC)

So about 1803 thousand million furlongs per fortnight (tmfpfn). Thanks! Gawaon (talk) 23:52, 23 March 2025 (UTC)

I requested on Template talk:Convert. The MOS:UNIT section mentions strong national ties and discusses non-scientific usage for US units, UK units and then puts Hands as an example (a UK/US unit) for all other articles. I would swap Hands for Tmcft as the example, or something else to make it clearer. Commander Keane (talk) 11:43, 23 March 2025 (UTC)

It states in the article Tmcft that the "cubic kilometer (km3) is the standard unit used by the Central Water Commission of the Government of India". As this is primarily of interest to people in India, and India has a government policy of using the System International only, see Metrication in India the sources listed must be more than 60 years old. I personally think there is probably no need to even list TMCFT. It's just a confusing unit. Avi8tor (talk) 12:31, 23 March 2025 (UTC)

A Google news search shows extensive recent Indian newsmedia usage, often in the title of articles (example given above, one week old). Commander Keane (talk) 13:06, 23 March 2025 (UTC)

Oh dear. Are we going to have the whole lakh/crore thing again? --Redrose64 🌹 (talk) 15:49, 23 March 2025 (UTC)

The corresponding unit in the US would be the acre-foot, which would be known to those concerned with US dams and reservoirs, but unknown to the general public and probably to water professionals from other countries. According to "List of dams and reservoirs in the United States" there are an estimated 84,000 dams in the United States; it's inconvenient to figure out how many of those have Wikipedia articles. But if we look at the articles that transclude the "Acre-foot" article, it's only about 150, and roughly half of those are about units of measure, not bodies of water. So I infer that articles about US dams and reservoirs don't usually mention acre-foot. So perhaps articles about similar bodies of water in India shouldn't mention Tmcft. Jc3s5h (talk) 23:40, 23 March 2025 (UTC)

Until yesterday I hadn't heard of Tmcft or acre-foot. Hoover Dam uses acre-foot. I am not aware of the lakh/crore thing. I am just concerned about article writers being able to input a value from a source, editors easily being able to verify that value from the source and for readers to understand that value (through conversion). Commander Keane (talk) 00:02, 24 March 2025 (UTC)

I've known about acre-feet for many years. More than 50 years ago I helped a couple of mathematicians figure out how much an acre-foot weighed by reciting "a pint's a pound the world around" (they had gotten to how many gallons there were in an acre-foot, but didn't know how much a gallon weighed). Donald Albury 00:47, 24 March 2025 (UTC)

I will just add that Wivenhoe Dam uses ML for reservoir volume and converts it to both imp and US gallons. I can anticipate the troubling temptation for Indian editors to add Tmcft there if {{convert}} is updated. And should km3 be added as well? We need some MoS guidance on this. Meanwhile Srisailam Dam is difficult to read. P.S. some guidance on m3 versus cumecs would be good also. Commander Keane (talk) 01:37, 24 March 2025 (UTC)

"I infer that articles about US dams and reservoirs don't usually mention acre-foot" – I don't think that's correct. (All you can infer from your data is that few of these articles transclude acre-foot.) I clicked half a dozen random blue links in List of dams and reservoirs in the United States to check the units for capacity. I found US gal, acre-feet, acre-feet, no capacity given, m³, acre⋅ft. Based on this random selection, it looks like many (maybe a majority) of these articles use acre-foot. — Chrisahn (talk) Chrisahn (talk) 02:50, 24 March 2025 (UTC)

Searching for variants: acre-foot 114 articles; acre-feet 1,419 articles; acre-ft 2,867 articles. — Chrisahn (talk) 03:02, 24 March 2025 (UTC)

Is there still opposition to adding Tmcft to {{convert}}? Code: tmcft; Alternate: Tmcft; Display tmcft.

Looking above, @Avi8tor, @Dondervogel 2 and @NebY expressed concern, but that may have been resolved if they read over the comments.

The state of reservoir/dam units is a mess across Wikipedia with acre-feet, megalitres, million tons and tmcft all getting used and converted to various other units. What to primarily display and convert to can be tackled in the future, at the moment I just want to resolve {{convert}} regarding Tmcft. Commander Keane (talk) 10:48, 29 March 2025 (UTC)

My position on tcmft has not changed. This unit has zero benefit. It can be replaced by billion cu ft in all articles that use tcmft.

One editor stated that "billion" is ambiguous in India. If that statement is accurate, my position (on the use of "billion" throughout Wikipedia) would change. Is it accurate? Dondervogel 2 (talk) 13:42, 29 March 2025 (UTC)

Re ambiguity, I read that as a reasonable guess about the origins of tmcft rather than as a statement that "billion" is currently ambiguous in India. OTOH, [note] to our Long and short scales says it still varies, but on the third hand that statement's not sourced. NebY (talk) 15:25, 29 March 2025 (UTC)

The Manual of style states litres primary with whatever suffix is appropriate and then a conversion to a listed unit. I think adding a unit used only in india that looks to be obsolete does not benefit the worldwide readers of Wikipedia. I second Dondervogel 2 Avi8tor (talk) 14:13, 29 March 2025 (UTC)

The fundamental question is whether MOS:UNITS should be extended to allow use of tmcft, and if so whether to allow it as a primary unit (as various of the units mentioned above are) and/or as a secondary, parenthetical unit. You haven't gained consensus for adding it to MOS:UNITS as a primary unit, either by itself or as a general provision for units used in India, and it hasn't been added. It's very hard to imagine consensus being reached for it to be added as a secondary unit, either by itself or as a general provision for units used in India, and certainly there's been no such addition. Adding tmcft to {{Convert}} would to some extent give the impression that its use was MOS-compliant and would facilitate its use, even though that use is contrary to MOS:UNITS as it stands. NebY (talk) 15:13, 29 March 2025 (UTC)

@NebY: as it stands MOS:UNITS says

In all other articles, the primary units chosen will be SI units (such as kilograms), non-SI units officially accepted for use with the SI, or such other units as are conventional in reliable sources discussing the article topic

(emphasis mine). There is no need to write in a provision for every country and usecase, it is already covered. Unless you interpret that passage differently? I agree that secondary units are not needed.

@Avi8tor: I don't see how it is obsolete, I already linked to Google news above which has since been updated to show tmcft used in the title of an article two days ago. Also, I don't think Wikipedians use obsolete units to be purposefully obscure. I am not sure what your comment on litres was about.

@Dondervogel 2: This unit has zero benefit, the unit's (or abreviation's) benefits are for article writers to put in the value from source and editors to check that value, all without knowing what a tmcft is ({{convert}} will take care that). It is incidental that Indian readers will understand the value. Commander Keane (talk) 17:11, 29 March 2025 (UTC)

That part of MOS:UNITS does not prescribe that we change primary units according to what the sources on that subject use in different countries. We do provide for changing units according to country In non-scientific articles with strong ties to the United States and In non-scientific articles with strong ties to the United Kingdom, but that is all. We set great store by uniformity in the expression of quantities across the encyclopedia.

As for your third point, we do not choose which units appear in our articles for the benefit of editors. We do it for our readers. If it is as you say, incidental that Indian readers will understand the value, then there is no case for using tmcft in our articles. NebY (talk) 17:35, 29 March 2025 (UTC)

It has zero benefit because we have a perfectly good equivalent unit that most readers will understand without needing to click on a link. If you are looking to a change to MOSNUM, I suggest adding this clarifying text to make things crystal clear:

• "Where there is a choice between an obscure unit (e.g., tmcft) and a widely understood unit with identical meaning (e.g., billion cu ft), use the widely understood unit with identical meaning."

Dondervogel 2 (talk) 19:45, 29 March 2025 (UTC)

I have a better understanding now. Tmcft is not a unit, it is an abbreviation. MOS:UNIT (talking about units) prescribes SI or SI-accepted for primary units of volume (excluding the US) unless the sources use something else. Verifiability exists for editors and readers alike and it says we have to be able to check information, which rules out editors converting tmcft in their calculator and using km3 as the primary unit. The primary unit is ft3.

That leaves us with billions of ft3. This will make verifiability a little harder and result in verbose wording and/or exponential notation. I think the choice to accept that should be up to each article but I also see the logic in avoiding tmcft altogether.

The MoS could say "abbreviations obscuring the base unit should be avoided" which would resolve tmcft and cumecs (m3/s) that I mentioned above.

I will leave it at that I think. Commander Keane (talk) 11:29, 30 March 2025 (UTC)

Sounds reasonable. Gawaon (talk) 17:53, 31 March 2025 (UTC)

"2025–present"

It seems ridiculous to me that this needs to be discussed, but I'm seeing it regularly in articles about sportspeople and bands, particularly, to describe something that started this year and has not yet ended. "2025–present" is a nonsensical daterange because 2025 is the present. It's like saying "2025–2025". The second date must surely be after the first, or else it makes no sense. Also, it implies that whatever is being referred to will continue beyond this year, which would be predicting the future.

Can we have something in the MOS to disallow this practice? Thanks, Bretonbanquet (talk) 00:10, 29 March 2025 (UTC)

For the automobile project we rely on Template:Infobox_automobile#Production. This says "However, 2025– is preferable to 2025–present while we are still in 2025." It would be nice to have something in MOS rather than a template's instructions.  Stepho  talk  00:38, 29 March 2025 (UTC)

Something can only begin at one moment in time—how much precision to use when specifying when that moment was is largely a pragmatic choice. When we say something began in 2025, we mean it began at some specific point during that calendar year. Remsense ‥ 论 00:42, 29 March 2025 (UTC)

Yes, and if it began, it began in the past. Dondervogel 2 (talk) 10:38, 30 March 2025 (UTC)

I would rather not see a watchlist flooded on 1 Jan 2026 with updates changing "2025–" to "2025–present". "{currentyear}–present" is just fine and I don't see an issue. Indefatigable (talk) 01:21, 29 March 2025 (UTC)

2025-present is future proofing the article in case no one edits it past 2025. — Masem (t) 01:26, 29 March 2025 (UTC)

Despite the fact that it makes no sense now? What does the "present" actually refer to that differs from "2025"? Is guessing that whatever it is will go beyond 2025 more important than the possible risk of it going out of date? Bretonbanquet (talk) 01:31, 29 March 2025 (UTC)

• Everyone take a look at WP:PRESENT. EEng 02:22, 29 March 2025 (UTC)

  Now, 2025–present (as of 2025) would look particularly ridiculous. After reading that section, I'm still not sure what the favourite solution is, assuming there is any? Gawaon (talk) 08:24, 29 March 2025 (UTC)

  Per Gödel's incompleteness theorems, it is inevitable that any attempt to describe the world in a uniform manner will include inelegant statements. (With apologies to Gödel.) NebY (talk) 10:38, 29 March 2025 (UTC)

The intended meaning of "2025-present" seems clear to me. Dondervogel 2 (talk) 09:40, 29 March 2025 (UTC)

What do you consider it to mean? Bretonbanquet (talk) 16:36, 29 March 2025 (UTC)

I interpret it to mean "between some time in the past (in the year 2025) and the present". I see no other logical interpretation. Do you? Dondervogel 2 (talk) 19:35, 29 March 2025 (UTC)

2025 is NOT the present. Most of it is the future, and every second of 2025 that is not in the future is in the past. Once you subtract the past and the future, what is left is less than a nanosecond. It's also less than a quectosecond. Dondervogel 2 (talk) 00:40, 30 March 2025 (UTC)

If the date isn't going to be narrowed down any further than "2025", it absolutely is the present. What other year could be the present year? If you clarify the date further, e.g. "February 2025", sure, that's the past. "15 July 2025" is the future. "2025" is the present, if the year is all you're going to give. Whatever the "intended meaning" may be, and it will differ from reader to reader, it needs to be a lot clearer than "2025 to present" in order to be meaningful. If a sportsperson has a contract which began in January and is ongoing, or if their contract begins in August and is open-ended, then by your logic, the subheading "2025–present" suits both scenarios, even though they're describing completely different things. Don't rely on a reader to understand your "intended meaning". Just be clearer, it's really easy. Bretonbanquet (talk) 17:14, 30 March 2025 (UTC)

I accept readers' interpretations can differ, so it's better to be explicit. What is your proposed easy and explicit alternative? Dondervogel 2 (talk) 18:36, 30 March 2025 (UTC)

Simply being more explicit by adding the month of the year would suffice. After the end of 2025 it could be left as is, or reduced simply to 2025, it would not matter either way. So it would be future-proofed, which was a concern of other editors. "2025–" would also work for me, although I know others are not keen on that. Honestly, I would prefer practically any other solution. Bretonbanquet (talk) 22:02, 30 March 2025 (UTC)

So if an event starts on Tuesday (1 April 2025), would you write "April 2025–" on Wednesday? Dondervogel 2 (talk) 22:38, 30 March 2025 (UTC)

In that case, "2025–" would suffice. "April 2025–present" seems nonsensical to me, but at least it's more explicit than "2025–present" and would read a lot better once April was over. Bretonbanquet (talk) 08:18, 1 April 2025 (UTC)

We should avoid having open ranges per MOS:DATETOPRES. I agree that "2025–present" (while we're still in 2025) is nonsensical, so I regularly replace it with "Since 2025". It's future-proofed even once we hit 2026 and doesn't have the MOS:RELTIME issue officially requiring the

2025–present (as of April 2025)

hideosity—I mean, I get the intent there but that is just a really, really awful construction. In active articles, of course, "Since 2025" would quickly get replaced with the "2025–present" range once 2026 rolls around. —Joeyconnick (talk) 06:44, 5 April 2025 (UTC)

But why? "Since 2023" is still perfectly fine, and will remain so, until there is reason to add an a specific end date because there is one. Gawaon (talk) 16:55, 6 April 2025 (UTC)

"Since 2025" seems to me to be much more ridiculous than "2025-present" in situations like this. "Since 2025" seems much more explicit about 2025 being in the past, while "2025-present" can be read as "starting in 2025 and continuing to the present) regardless of whether the present is also in 2025. --User:Khajidha (talk) (contributions) 14:23, 9 April 2025 (UTC)

Date generation templates

I sometimes view the source codes in articles using birth date, death date, and start date templates; in some cases where the month or day corresponds to a single-digit number, I notice a preceding zero, but in other cases, it's just the single digit. While preceding zeros for single digits are customary in some formats, is there not a set rule for doing the same in the aforementioned templates? TheAmazingCoffeeMan (talk) 19:01, 29 March 2025 (UTC)

Ordinals in article titles

(Would post this on Wikipedia talk:Naming conventions (numbers and dates), but there're many more watchers here.)

Per Talk:Fifth-century Athens § Requested move 8 April 2025, it would be internally consistent to title the article Athens in the fifth century BC, but I'm not aware of any articles using spelled-out ordinals for centuries, and many other articles that spell out ordinals nevertheless use numeral forms in the article title. What's correct here? If AD / CE labels are anything to go by, we would prioritize in-article consistency, but Wikipedia:Naming conventions (numbers and dates) strongly suggests otherwise. Remsense ‥ 论 19:23, 9 April 2025 (UTC)