This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Manual of Style This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Wikipedia:WikiProject Dates Wikipedia talk:Date debate Wikipedia talk:Naming conventions (calendar dates) Wikipedia talk:Timeline standards Wikipedia:Measurements Debate Wikipedia talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 2 sections are present.

A string of edits by Jc3s5h and JMF. introducing and removing changes to Wikipedia:Manual of Style/Dates and numbers § Common mathematical symbols, raise issues that I believe should be discussed.

1. The most recent change, permalink/1247903136, has the comment This page does not cover matrix operations., however, I do not see anything in the article to support a restriction to numerical operations.
2. The most recent change reinstates the link to dot product, despite the comment.
3. There seems to be disagreement on the division sign.

The questions that I wish to raise are

1. Should that section mention {{tmath}} or <math>...</math>?
2. Are vector operations within the scope of the article? Regardless of the answer, the dot and cross products should be treated consistently.
3. Should there be two new rows for dot and cross product?
4. Should there be a row for tensor product?
5. Is obelus unhelpful since it has three forms?
6. Should the Division sign (U+00F7 ÷ DIVISION SIGN) be deprecated in favor of Slash (U+002F / SOLIDUS)?
7. Should U+2215 ∕ DIVISION SLASH be explicitly deprecated in favor of Slash?
8. Should the use of "x" and "*" as multiplication signs be explicitly deprecated in favor of U+00D7 × MULTIPLICATION SIGN?
9. Should that section show the LaTeX markup for characters in addition to the HTML character entity references?

-- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 27 September 2024 (UTC)[reply]

1. I think the page should be devoted to general articles, and <math> should be reserved for advanced math and science articles.
2. Vector operations are not currently in the scope of the project page, and I'm not thrilled about adding them.
3. Dot product and cross product should certainly not be addressed in the same row as any scalar operation. The multiplication dot should certainly not be linked to the "Dot product" article nor should the multiplication cross be linked to the "Cross product" article.
4. Tensor products should not be covered in this project page because they're too advanced.
7. I'm not willing to spend 5 or minutes figuring out what this line means.
8. The asterisk as a multiplication sign should be limited to articles about computer languages that use it as such.
9. LATEX should not be mentioned, since we don't use it in Wikipedia. This isn't a style manual for writing outside of Wikipedia.

Jc3s5h (talk) 19:45, 27 September 2024 (UTC)[reply]

Tbh, I wondered what this extensive list is doing in the MOS in the first place. Glossary of mathematical symbols does it better. It really needs to be reduced to cover only those symbols that have a styling issue: scalar division and multiplication.

• The grade-school division sign should be formally deprecated, for reasons explained at division sign.
• The 'ordinary' slash (002F) should be preferred over 2215, same logic as straight quotes and curly quotes.
• I prefer U+00D7 × MULTIPLICATION SIGN over x, for biology as well as math but maybe that needs debate.

𝕁𝕄𝔽 (talk) 20:04, 27 September 2024 (UTC)[reply]

Comments:

• I see no good reason to prohibit using a division sign to express division. That seems absolutely fine. The division sign article seems to say it might be confusing in Italian, Russian, Polish, Danish, Norwegian, or Swedish, but this is the English Wikipedia. We use points as decimal separators also, and we use commas as a thousands separator too, although that might be confusing in other languages.
• I also see no good reason to prohibit using an asterisk for multiplication; it seems well-understood, easy to type, unambiguous, and common in practice. I agree with not using "x" for multiplication, although I think it's OK to express "by" relationships for 2x4 lumber, 4x8 sheets of plywood, and 4x4 trucks.
• <math>x</math> (i.e., ) looks different from ''x'' (i.e., x), and those look different from {{math|''x''}} (i.e., x), at least on my screen, and seeing mixtures of those in the same article can be a bit annoying (especially if they are near each other).

—⁠ ⁠BarrelProof (talk) 21:46, 7 October 2024 (UTC)[reply]

Asterisk means convolution (which is somewhat related to the idea of "multiplication" but should not be confused with the usual multiplication). Its use as a substitution for "×" or "⋅" is a bad habit from the old days of poor technology (but it was never used as such in professional typesetting) and has no excuse nowadays. — Mikhail Ryazanov (talk) 22:12, 7 October 2024 (UTC)[reply]

Convolution would only be a matter to consider in very mathematically sophisticated specialized contexts. It's not something most people have ever encountered. Even for those who use it, it would often be expressed using summation or integration instead. —⁠ ⁠BarrelProof (talk) 22:21, 7 October 2024 (UTC)[reply]

I don't think that this is a good reason to make exceptions to tolerate/promote sloppy typography (moreover, in some computer fonts the ASCII asterisk looks more like a superscript than a binary operator consistent with +, −, = and so on).

I don't think we should feel responsible for how Wikipedia is rendered in all possible fonts. We should remember that everyone is supposed to be able to edit Wikipedia articles. In an article that isn't about mathematics, or at least isn't using it beyond the 10th grade level, f = 1.8 * c + 32 seems basically OK to describe conversion from degrees C to degrees F. It's tricky enough that we tell people to pay attention to the difference between "-", "–", "—", and "−", and to not use italics for the numbers in that formula, although I support those instructions. —⁠ ⁠BarrelProof (talk) 03:37, 8 October 2024 (UTC)[reply]

Nobody should complain about otherwise good edits that include "lazy" typography. Those edits are 100% OK and a net improvement to Wikipedia. Other editors who care about typography and MoS can clean up the markup and character choices later. Wikipedia is a collaborative project. Indefatigable (talk) 15:46, 8 October 2024 (UTC)[reply]

Using an asterisk to represent multiplication is programming language syntax; I don't think this is common or even well-known among non-programmers. isaacl (talk) 01:47, 20 October 2024 (UTC)[reply]

I agree we should discourage use of "*" as a multiplication symbol. I agree it's easy to type, so if one editor writes "y = m*x + c" in an otherwise correct edit, the response should not be to revert that edit, but to replace it with "y = mx + c" or other approved alternative. Dondervogel 2 (talk) 10:40, 20 October 2024 (UTC)[reply]

Using an asterisk for multiplication is absolutely known to non-programmers because that's what is used on the number pad on most keyboards in the US. --User:Khajidha (talk) (contributions) 14:28, 12 November 2024 (UTC)[reply]

Ah, but which came first - the * key, or its use in mathematical expressions? Forty-some years ago, I was taught that in computer code, the * character was chosen to avoid confusion with the letter x, since the × did not exist in either of the character sets that were in use at the time - ASCII and EBCDIC. It's the same with / vs. ÷ and indeed - vs. −. --Redrose64 🌹 (talk) 18:15, 12 November 2024 (UTC)[reply]

* appeared on many (but not all) early typewriters. When not present it was often replaced by a fraction key (1/2, 1/4, etc) Practically every computer terminal from the 1970s onward has a * key - but that's probably due to it being used by Fortran (1957). Early teletype keyboards typically used Baudot code encoding and did not have * - but these were more for telecommunications rather than programming. Fortran was invented at IBM and used punch cards/tape using IBM's BCDIC. The early variations of BCDIC had *, - and / but not +. + was added soon after. My take is that BCDIC tried to encode whatever was commonly used on typewriters - subject to the limitation of using only 64 characters. Fortran then assigned functionality to whatever was in that set. * looked the most like x without being a letter, so it got the job.  Stepho  talk  23:56, 12 November 2024 (UTC)[reply]

It would really behoove participants here, instead of just speculating from the armchair, to take the radical step of doing some research to actually find out the answer. * has been used, in math, to mean multiplication for three hundred years. See the bottom of p. 66 of [1]. EEng 07:15, 13 November 2024 (UTC)[reply]

I didn't mention that paper, because I'm not in the habit of searching through 100-year-old academic journals. Now, 100-year-old magazines is a different matter, witness my stacks of boxes of The Railway Magazine back to 1902 (gaps between 1902 and 1939, complete from 1940 onward). --Redrose64 🌹 (talk) 12:02, 13 November 2024 (UTC)[reply]

FORTRAN was a decade earlier than ASCII and EBCDIC. What the first FORTRAN compiler used was the scientific BCD character set of the IBM 704, which replaced the older Percent (%) and Lozenge (U+2311 ⌑ SQUARE LOZENGE) with parentheses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:35, 13 November 2024 (UTC)[reply]

'Phase 1' or Phase one'? This appears to be a case that's not explicitly covered.

The AP Stylebook recommends using figures for sequences in its section on "Numbers": "Also use figures in all tabular matter, and in statistical and sequential forms", from which I infer that for sequences, such as 'phase 1', figures should be used for clarity and consistency.

Similarly, chapter 9 of The Chicago Manual of Style advises using figures when referring to a sequence.

I propose adding similar explicit advice to this section of the MOS.

-- Jmc (talk) 20:10, 19 October 2024 (UTC)[reply]

• As usual, what's needed before something's added to MOS is examples of this being an issue on multiple articles -- see WP:MOSBLOAT. Are editors not able to work this out for themselves on individual articles? Anyway, why does the word "Phase" need this in particular? Why not "Section" and "Part" and any other words like that?
  The advice from APA and CMS are great if you're making up a new sequence for your thesis, but that's not us. It's hard to imagine an article using a phrase like "Phase 1" or "Phase One" on its own -- that is, other than in imitation of the phrasing of sources. So follow the sources; for example, Economic Stabilization Act of 1970 refers to Phase I and Phase II and Phase III., because that's the form the Act uses. We're not going to override that in the name of consistency with other, unrelated articles. EEng 22:00, 19 October 2024 (UTC)[reply]

  To clarify: I'm using 'Phase' purely as an example. The issue of using figures for sequences applies to any sequence. including 'Section' and 'Part' - and other examples: "Game 3", of a sequence of nine; 'Chapter 9' of a sequence of 24; 'Week 4' of a limitless sequence.

  I raise this issue in the context of differing editorial practices in the British Post Office scandal article, where both figures and words have been used to reference the same phases and weeks of the inquiry. I sought guidance from the MOS and found none.

  I'd be content to follow the sources, without adding bloat to the MOS, if I could be confident that that's an accepted stylistic convention in this instance. -- Jmc (talk) 22:27, 19 October 2024 (UTC)[reply]

  Such names are very often established by authoritative sources and constitute proper names; we should follow the sources rather than renaming them. Per EEng, we only need a MOS guideline if our sources don't provide clear names and either there is dissent among editors or consistency across articles would be of significant benefit. In the Post Office case, I see the phases have been titled Phase 1, Phase 2 etc by the inquiry[2] so unless the inquiry's inconsistent, we can follow that source. Still, I see that this is a live issue at that British Post Office scandal article, so it would be wrong to establish a new guideline or issue some sort of MOS talk-page ruling without the knowledge of the other editor; pinging MapReader. NebY (talk) 14:56, 20 October 2024 (UTC)[reply]

  Between May 1966 and December 1989, multi-episode Doctor Who stories could have titles in any of the four combinations of (i) "Episode ..." or "Part ..."; (ii) numbers as figures or as words. The decision as to which format to use was probably in the hands of the series producer, but in our articles about each story, we give the actual title shown on screen - except that where the on-screen title is all-capitals, we reduce it to title case. Certain Doctor Who reference books do the same, so we're following the sources. --Redrose64 🌹 (talk) 18:18, 20 October 2024 (UTC)[reply]

  The question raised was "differing editorial practices in the British Post Office scandal article". Sounds like a matter of internal consistency, which is different. For all manner of things -- this being one IMO -- we might not need consistency among articles, but it does look bad within articles. Surely we already have a rule addressing that general issue tho? Herostratus (talk) 13:24, 21 October 2024 (UTC)[reply]

  I think we don't. In articles on TV series it's common to have expressions like "season 3" and "episode 7", which seem to go against our current wording (use words for numbers below 10). Gawaon (talk) 16:37, 21 October 2024 (UTC)[reply]

  It is indeed a matter of internal consistency and it does look bad, as Herostratus says. Within the one article (British Post Office scandal), we have (e.g.) both "Phase 3 hearings" and "Phases five and six". Is there in fact a rule addressing this general issue? -- Jmc (talk) 18:47, 21 October 2024 (UTC)[reply]

  From Wikipedia:Manual of Style/Dates and numbers#Numbers as figures or words: "Comparable values nearby one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently." Unless you are dealing only with series with fewer than 10 seasons each with fewer than 10 episodes, it is more in line with MOS to give all season and episode numbers in digits rather than words. --User:Khajidha (talk) (contributions) 13:15, 22 October 2024 (UTC)[reply]

  True, but series with less than ten seasons aren't all that rare, and there are also miniseries with less than ten episodes. Gawaon (talk) 16:39, 22 October 2024 (UTC)[reply]

  Whether or not it's in line with MOSNUM, we frequently – I suspect in the vast majority of cases – give series/season and episode numbers in digits. I've been dipping into Wikipedia:Good articles/Media and drama#Television. Articles on individual episodes do routinely begin e.g. " the ninth and final episode of the first season" but with digits in the infobox. Articles on a season/series list episodes using digits, and articles on a show list series/seasons and episodes with digits, regardless of whether there are more or less than ten, in keeping with the examples in Wikipedia:Manual of Style/Television#Episode listing. Articles are often titled <show> season <n> where n is a digit, never a word, in accordance with Wikipedia:Naming conventions (television)#Season articles. Sampling our WP:Featured articles#Media, I see the same treatment in titles, infoboxes, and listings.

  I very much doubt that editors would accept changes to those FAs and GAs to bring them into line with MOS:NUMERAL, that FA and GA assessors will start to apply MOS:NUMERAL in such cases, that any move requests would succeed, or that MOS:TV and WP:TVSEASON will be brought into line with the current MOS:NUMERAL. Changing MOS:NUMERAL might be easier. NebY (talk) 08:20, 23 October 2024 (UTC)[reply]

  I agree, a small addition to MOS:NUMERAL might be a good thing. Gawaon (talk) 17:00, 23 October 2024 (UTC)[reply]

  Your final sentence doesn't follow from your statement. It would be more in keeping with the MOS to give all in words. MapReader (talk) 11:16, 23 October 2024 (UTC)[reply]

• Generally concur with EEng and NebY. It's clear that certain conventions adhere strongly to certain things, and these conventions will be readily apparent from the source material about those things. WP is not in a position to impose an artificial WP-invented consistency on them that makes no sense for those familiar with the subject (e.g. referring to "issue number seven" of a comic book or "the three ball" in a game of pool). Where nothing like a consistent convention can be observed for the topic at hand, then MOSNUM already provides us with a default to fall back to: use "one" through "nine", then "10" onward. This is the case with centuries, for example. There is no overwhelming source preference for either "third century BC[E]" or "3rd century BC[E]" in reliable sources. (Books tend to prefer the former, journals use the latter more than books do because journal publishers are more interested in compression/expediency. Scroll through first 10 pages of GScholar resuls here and see how much variance there is, and how frequent the numeral style is compared to "traditional" spelling-out. That said, GScholar searches do include some books as well as journals.) Following our default system, we naturally end up with "third century BC" and "12th century BC". (Of course, our material doesn't perfectly follow this; our editors are human, not robots. Well, mostly.)  — SMcCandlish ☏ ¢ 😼  15:04, 24 November 2024 (UTC)[reply]

Which style I should use for micro seconds? Does μs relative to "Do not use precomposed unit symbol characters"? DungeonLords (talk) 04:44, 30 October 2024 (UTC)[reply]

The 2 characters "μ" and "s" are just fine. The precomposed symbols advice is to guard against particular fonts that combine them into a single character because many software readers for the sight impaired do not know all of these symbols.  Stepho  talk  04:53, 30 October 2024 (UTC)[reply]

But do use μ, not "u". The latter was something of an early-Internet halfassed approach, but we have Unicode now.  — SMcCandlish ☏ ¢ 😼  15:09, 24 November 2024 (UTC)[reply]

Greetings and felicitations. I assume that such constructions as "Wednesday, 24 February" are discouraged, but I can't find it in the text or the this page's archives. (The comma seems unnecessary to me.) May I please get confirmation or refutation? —DocWatson42 (talk) 04:28, 4 November 2024 (UTC)[reply]

• MOS:DATEFORMAT and MOS:BADDATE cover the allowed and disallowed formats. Unless the day of the week is vitally important then we leave it out.  Stepho  talk  06:16, 4 November 2024 (UTC)[reply]

  This specifically regards the "Hadaka Matsuri" article, and its Konomiya Hadaka Matsuri infobox, which includes the days of the week. —DocWatson42 (talk) 07:40, 4 November 2024 (UTC)[reply]

  Ah, the mysterious East. EEng 08:06, 4 November 2024 (UTC)[reply]

• Salutations and hugs and kisses to you too.
  • If your question is whether day-of-week should be gratuitously included with dates for no particular reason, the answer is No. That is, if the day-of-week is somehow relevant to the narrative, sure, include it, but otherwise no.
  • Assuming we're in some situation where (per the preceding) inclusion of day-of-week is indeed justified, maybe your question is how to append the D.O.W.
    • If the date is February 24 or February 24, 2024, then without doubt the right format is Wednesday, February 24 or Wednesday, February 24, 2024.
    • According to "Elite editing" [3] (whoever they may be -- search the text "inverted style" on that page), the corresponding answers for 24 February and 24 February 2024 are Wednesday, 24 February and Wednesday, 24 February 2024. To me that does seem right -- Wednesday 24 February 2024 (all run together, no commas at all) seems intolerable.

The question naturally arises as to whether MOS should offer advice on all the above. My answer, as usual, is provisionally No, per WP:MOSBLOAT. EEng 08:02, 4 November 2024 (UTC)[reply]

Looking at the article, the date is the 12th day of the Chinese year and the day of the week has no significance. I would remove the day of the week from all those dates in the infobox. For what it's worth, I spent most of the 1990s in Hong Kong/China. Major holidays based on the Chinese calendar treat the day of the week in the same way that we treat the day that Christmas falls on.  Stepho  talk  09:18, 4 November 2024 (UTC)[reply]

Okay—will do. Thank you both. ^_^ —DocWatson42 (talk) 09:21, 4 November 2024 (UTC)[reply]

The new 18th edition of The Chicago Manual of Style gives advice about commas in dates in ¶ 6.14. When giving examples they mostly give examples with words after the end of the date so the punctuation at the end of the date is illustrated. Some examples:

• The hearing was scheduled for 2:30 p.m. on Friday, August 9, 2024.
• Monday, May 5, was a holiday; Tuesday the 6th was not.

Jc3s5h (talk) 16:56, 4 November 2024 (UTC)[reply]

Concur with EEng on avoiding adding a rule about this, as more WP:MOSBLOAT. It's just a matter of basic writing sense, basic comma usage in competent English. Our MoS's purpose is not that of CMoS or Fowler's, trying to answer every imaginable usage question. Just those that have an impact on reader comprehensibility and/or recurrent editorial strife.  — SMcCandlish ☏ ¢ 😼  15:18, 24 November 2024 (UTC)[reply]

A question regarding spacing of percentage point (pp) usage. I have always assumed there is no space between the number and pp (e.g. 5.5pp not 5.5 pp), on the basis that you wouldn't put a space between a number and a percentage sign (5% not 5 %). There is no reference to this in the MOS, but the percentage point article uses it unspaced. It might be good to have it clarified in the MOS as I see regular changes adding spacing, which I am not sure is correct. Cheers, Number 57 23:49, 5 November 2024 (UTC)[reply]

• MOS:PERCENT says "omit space".  Stepho  talk  23:54, 5 November 2024 (UTC)[reply]

  Perhaps I am missing something, but as far as I can see, it says to omit space when using the percentage symbol (%) but nothing about when using pp? Number 57 00:21, 6 November 2024 (UTC)[reply]

  Apologies, I missed the "point" word in your question.  Stepho  talk  01:49, 6 November 2024 (UTC)[reply]

• % is essentially a constant factor (.01), but pp is more like a unit so my intuition says it should be spaced. I note that the basis point article uses a space before bp (mostly, anyway). I'll be interested to hear what others think. EEng 18:23, 6 November 2024 (UTC)[reply]

  You've got this back to front. Percent (%) is a standard unit symbol and should be spaced, whereas pp is a made up abbreviation, meaning you can put it anywhere you want, space or unspaced. I know MOSNUM says otherwise, which is WP's prerogative. In other words, if we need a rule, let's make one up and apply it, but there's no logic involved. Dondervogel 2 (talk) 21:06, 6 November 2024 (UTC)[reply]

• Dondervogel, "Percent (%) is a standard unit symbol and should be spaced". Huh? It's not an ISO unit symbol, is it. No spacing in English, unlike French. On pp, I agree with EEng: space it. Tony (talk) 11:10, 8 November 2024 (UTC)[reply]

  Absolutely. When it comes to peepee, always space it [4]. EEng 21:36, 8 November 2024 (UTC)[reply]

  Yes, "%" is an ISO standard unit symbol. Dondervogel 2 (talk) 12:45, 8 November 2024 (UTC)[reply]

  What is it the unit of? Gawaon (talk) 13:14, 8 November 2024 (UTC)[reply]

  Nothing. It's a dimensionless quantity. To the original q: I don't see "pp" used often, in fact rarely. It's probably better written out in full on first use, and if there are subsequent uses, follow the guidance at MOS:ACRO1STUSE. --Redrose64 🌹 (talk) 19:58, 8 November 2024 (UTC)[reply]

  It's used widely in election infoboxes where there isn't space to write it out. Number 57 22:25, 8 November 2024 (UTC)[reply]

  I will answer Gawaon's valid question in two parts. The first part is a quotation from ISO 80000-1:2009 (emphasis added)

  • In some cases, per cent, symbol %, where 1 % := 0,01, is used as a submultiple of the coherent unit one.
  • EXAMPLE 4
  • reflection factor, r = 83 % = 0,83
  • Also, per mil (or per mille), symbol ‰, where 1 ‰ := 0,001, is used as a submultiple of the coherent unit one.Since the units “per cent” and “per mil” are numbers, it is meaningless to speak about, for example, percentage by mass or percentage by volume. Additional information, such as % (m/m) or % (V/V) shall therefore not be attached to the unit symbol %. See also 7.2. The preferred way of expressing, for example, a mass fraction is “the mass fraction of B is w B = 0,78” or “the mass fraction of B is wB = 78 %”. Furthermore, the term “percentage” shall not be used in a quantity name, because it is misleading. If a mass fraction is 0,78 = 78 %, is the percentage then 78 or 78 % = 0,78? Instead, the unambiguous term “fraction” shall be used. Mass and volume fractions can also be expressed in units such as µg/g = 10-6 or ml/m3 = 10-9.

  Notice the deliberate space between numerical value (e.g., 83) and unit symbol (%). Dondervogel 2 (talk) 22:10, 8 November 2024 (UTC)[reply]

  The second part is a partial retraction, quoting from ISO 80000-1:2022, which supersedes the 2009 document:

  • If the quantity to be expressed is a sum or a difference of quantities, then either parentheses shall be used to combine the numerical values, placing the common unit symbol after the complete numerical value, or the expression shall be written as the sum or difference of expressions for the quantities.
  • EXAMPLE 1
  • l = 12 m - 7 m = (12 - 7) m = 5 m, not 12 - 7 m
  • U = 230 ⋅ (1 + 5 %) V = 230 ⋅ 1,05 V ≈ 242 V, not U = 230 V + 5 %

  The space is still there between numerical value (5) and percentage symbol (%), but I could not find an explicit reference to "%" as a unit symbol. I'm unsure how to interpret that change, but I'll report back here if I find further clarification. Dondervogel 2 (talk) 22:16, 8 November 2024 (UTC)[reply]

  I found this in NIST Special Publication 811

  • In keeping with Ref. [4: ISO 31-0], this Guide takes the position that it is acceptable to use the internationally recognized symbol % (percent) for the number 0.01 with the SI and thus to express the values of quantities of dimension one (see Sec. 7.14) with its aid. When it is used, a space is left between the symbol % and the number by which it is multiplied [4: ISO 31-0]. Further, in keeping with Sec. 7.6, the symbol % should be used, not the name "percent."
  • Example: xB = 0.0025 = 0.25 % but not: xB = 0.0025 = 0.25% or xB = 0.25 percent
  • Note: xB is the quantity symbol for amount-of-substance fraction of B (see Sec. 8.6.2).
  • Because the symbol % represents simply a number, it is not meaningful to attach information to it (see Sec. 7.4). One must therefore avoid using phrases such as "percentage by weight," "percentage by mass," "percentage by volume," or "percentage by amount of substance." Similarly, one must avoid writing, for example, "% (m/m)," "% (by weight)," "% (V/V)," "% (by volume)," or "% (mol/mol)." The preferred forms are "the mass fraction is 0.10," or "the mass fraction is 10 %," or "wB = 0.10," or "wB =10 %" (wB is the quantity symbol for mass fraction of B—see Sec. 8.6.10); "the volume fraction is 0.35," or "the volume fraction is 35 %," or " φB = 0.35," or "φB = 35 %" (φB is the quantity symbol for volume fraction of B—see Sec. 8.6.6); and "the amount-of-substance fraction is 0.15," or "the amount-of-substance fraction is 15 %," or "xB = 0.15," or "xB = 15 %." Mass fraction, volume fraction, and amount-of-substance fraction of B may also be expressed as in the following examples: wB = 3 g/kg; φB = 6.7 mL/L; xB = 185 mmol/mol. Such forms are highly recommended (see also Sec. 7.10.3).
  • In the same vein, because the symbol % represents simply the number 0.01, it is incorrect to write, for example, "where the resistances R1 and R2 differ by 0.05 %," or "where the resistance R1 exceeds the resistance R2 by 0.05 %." Instead, one should write, for example, "where R1 = R2 (1 + 0.05 %)," or define a quantity Δ via the relation Δ = (R1 - R2) / R2 and write "where Δ = 0.05 %." Alternatively, in certain cases,the word "fractional" or "relative" can be used. For example, it would be acceptable to write "the fractional increase in the resistance of the 10 kΩ reference standard in 2006 was 0.002 %."

  As with ISO 80000-1:2022, there is always a space between numerical value (e.g., 35) and the percentage symbol (%), but no mention of % as a unit symbol. Dondervogel 2 (talk) 22:38, 8 November 2024 (UTC)[reply]

  there is always a space between numerical value (e.g., 35) and the percentage symbol (%) – Maybe in NIST-world, but not here on Wikipedia (see MOS:PERCENT), so I don't see how any of that helps us with the issue at hand. EEng 23:29, 8 November 2024 (UTC)[reply]

  I was correcting a misconception that % is not a unit symbol when it is. At least it was until 2022. I find it best not to leave incorrect statements unchallenged or they take on a life of their own. Dondervogel 2 (talk) 00:24, 9 November 2024 (UTC)[reply]

  Um, OK, but you do realize that WP does not follow NIST's advice about spacing it, yes? EEng 00:44, 9 November 2024 (UTC)[reply]

  Yep, and I wasn't trying to change that. My contributions have been to

  • correct a factual error (yours)
  • respond to questions from Tony and Gawaon

  I have not weighed in on the main thread regarding percentage points because I don't expect my opinion (based not on NIST's utterings but on the ISO standards on which they are based) to be taken seriously, so why would I waste my e-breath? Dondervogel 2 (talk) 09:41, 9 November 2024 (UTC)[reply]

• It is not conventional to space "%" in English. Nearly no publishers do this, and our MoS doesn't say to do this or incidentally illustrating doing this, so don't do this. "pp" here is a unit abbreviation for percentage point ("the unit for the arithmetic difference between two percentages)", so space it. % is not a unit abbreviation/symbol, but a quantity symbol, so it's in a different class. It's more like the ~ in "~5 ml". That the spelled-out equivalent "approximately", like the spelled out "per[]cent", is spaced apart from the numeral is irrelevant.  — SMcCandlish ☏ ¢ 😼  15:24, 24 November 2024 (UTC)[reply]

MOS:UNITSYMBOLS currently requires a unit symbol after each value when listing dimensions separated by × (“1 m × 3 m × 6 m, not 1 × 3 × 6 m”). Could we have a carveout from this rule, and allow editors to use only a final unit when writing for infoboxes, and perhaps other places where space is limited?

Context: {{Infobox mobile phone}} currently has a preference for listing the dimensions of the product each on a separate line. This, and other parameters, can make the infobox very long. This is especially problematic for pages that cover multiple products or versions of a product; see dimensions in Samsung Galaxy S21 infobox. In order to cut down these infoboxes, we could be using a single line for all three dimensions, but the unit after each value feels unnecessary, and can cause line overflow.

Prior discussion: Wikipedia talk:Manual of Style/Dates and numbers/Archive 145#Repeating units in ranges and dimensions, where the potential for confusion with actually multiplying values was pointed out. I think this is a minor concern in general, but worth considering in prose, or in contexts where the values could be ambiguous. — HTGS (talk) 04:17, 11 November 2024 (UTC)[reply]

Where space is limited, it makes sense to present a single compound unit, equal to the product of the separate units. For the example given, the compound unit symbol would be m³. Dondervogel 2 (talk) 12:13, 11 November 2024 (UTC)[reply]

Who ever heard of a phone advertised as 5 cc ? People are more interested in it being wide and tall but very thin. This necessitates stating each individual dimension.  Stepho  talk  22:40, 11 November 2024 (UTC)[reply]

No, what Dvogel means is you'd write that a certain phone measures 146 x 71.5 x 7.65 mm³. Having clarified that, I'm bound to say that that would, of course, confuse 99% of our readers. EEng 22:47, 11 November 2024 (UTC)[reply]

Gotcha. As well as confusing most readers, it would also be different to 1 by 3 by 6 m, which is allowed.  Stepho  talk  23:30, 11 November 2024 (UTC)[reply]

To be clear for those playing along at home, while the canonical formuations are 1 m by 3 m by 6 m and 1 m x 3 m x 6 m, MOS currently makes an exception allowing 1 by 3 by 6 m (specifically in the case where all the quantities are in the same unit -- in this case metres), but no corresponding exception allowing 1 x 3 x 6 m. While it may offend purists, I really don't see why the exception shouldn't be extended to that last case as well. Thoughts? EEng 23:39, 11 November 2024 (UTC)[reply]

Thank you for clarifying my intent. And for making me chuckle. LoL

For a 3 dimensional object, one can write either 146 mm x 71.5 mm x 7.65 mm or 146 x 71.5 x 7.65 mm³. I agree the former is clearer, but the latter uses less space, which can be a consideration. There is no difference in meaning.

I guess one could also write 146 x 71.5 x 7.65 mm, but then we have a length, not a volume. It would be clearer to write that length as 79.86 m. Dondervogel 2 (talk) 23:42, 11 November 2024 (UTC)[reply]

one could also write 146 x 71.5 x 7.65 mm, but then we have a length, not a volume – Formally perhaps, but you could say the pretty much the same about 146 by 71.5 by 7.65 mm, and yet we allow it. No one will think that 146 x 71.5 x 7.65 mm means the length 79.86 m (i.e. 79860 mm). In context readers will understand it for what it is. I'd like to hear what others think about my proposal. EEng 23:56, 11 November 2024 (UTC)[reply]

Seconded EEng's proposal - simple and clear.  Mr.choppers | ✎  04:36, 14 November 2024 (UTC)[reply]

EEng is, of course, correct. At {{convert}} we sometimes are asked how the duplicate mm units can be removed to save space (the trick is to use xx in convert) and we tell them that omitting repeated units is ok if space is limited. May as well make it official. Johnuniq (talk) 05:51, 14 November 2024 (UTC)[reply]

EEng is, of course, correct. – Of course -- even Dondervogel says so. EEng 06:37, 14 November 2024 (UTC)[reply]

I also support the proposal.  Stepho  talk  05:53, 14 November 2024 (UTC)[reply]

I thought this was a joke and burst out laughing on a train, which got me a weird look from a fellow passenger. Anyhow, I too support allowing the single unit after x symbols per EEng and John. Toadspike [Talk] 17:31, 18 November 2024 (UTC)[reply]

:( — HTGS (talk) 23:34, 18 November 2024 (UTC)[reply]

• It's tiresome to have to write (and read) units multiple times when multiplication signs are used. Tony (talk) 09:47, 14 November 2024 (UTC)[reply]
• As the person who proposed this in the first place, I too support EEng’s proposal. I will carry on working on the infobox, and leave the written MOS to others. I imagine the purists might be happy if we left some comment or endnote about making sure the measurements are not potentially ambiguous though?

And, for anyone who cares, there are already pages where this is in sensible use: List of photographic film formats. — HTGS (talk) 23:34, 18 November 2024 (UTC)[reply]

I see people adding conversions to mentions of screen sizes and wheel dimensions - is this really necessary? Even in Germany or New Zealand, automobile and bike wheels are universally referred to by inches; rim diameters are expressly defined in inches in the EU regulations. To me, adding conversions for these types of dimensions adds unnecessary clutter, harming readability for no return whatsoever. I haven't read the entire MOS today, apologies if I missed a mention of these situations.  Mr.choppers | ✎  17:24, 13 November 2024 (UTC)[reply]

It looks like sizing bike wheels in inches is not universal. I see many charts in the I-net such as this that use both metric and imperial/American units for bike wheels and tires. Whether the convert template handles them correctly is another issue. Donald Albury 17:43, 13 November 2024 (UTC)[reply]

On the matter of wheel sizes, not all are inches. See this post and my reply. Even for a conventional non-Denovo wheel, the dimensions are a bastard mixture: "195/65 R 15" means a tyre that is 195 mm wide on a 15-inch rim. --Redrose64 🌹 (talk) 19:10, 13 November 2024 (UTC)[reply]

Yes, there is the Michelin TRX and the Denovo. Just as we wouldn't convert the "195" when we write 195/60 R15, I don't think we ought to convert the diameter either. I would treat all of these tire dimensions as one would nominal measurements, rather than inserting unnecessary templates. Bicycle tires, meanwhile, proved more varied than I was aware of.  Mr.choppers | ✎  04:33, 14 November 2024 (UTC)[reply]

I agree with Mr.Choppers on this subject. I think wheels sizes on cars are a compromise between the USA and the rest of the world. There are metric rims on older vehicles but pretty rare on new vehicles. Avi8tor (talk) 11:40, 14 November 2024 (UTC)[reply]

@Avi8tor: - I was actually triggered by you converting screen dimensions, but five minutes online showed me that the modern world has indeed begun dropping the use of inches for screens. My gut was wrong.  Mr.choppers | ✎  13:36, 14 November 2024 (UTC)[reply]

Many people around the planet know only millimetres, so it makes sense to have both. I notice in France the data information on television screen size have it in both inches and millimetres. Avi8tor (talk) 17:57, 16 November 2024 (UTC)[reply]

• I agree with Aviator, who didn't mention that aviation uses "feet" for altitude—needs conversion in my view. Tony (talk) 07:30, 22 November 2024 (UTC)[reply]

  I thought that "feet" used for altitude is not a measure of distance but of pressure, so perhaps it should be converted to pascals first. I'm not saying one should not then convert to metres too - only that the conversion would need some care. Dondervogel 2 (talk) 22:06, 22 December 2024 (UTC)[reply]

I'm inviting fellow editors to figure out whether Religious perspectives on Jesus should use BC / AD or BCE / CE. The issue is that the article mixes eras and when I went back to see which was first, I saw it originally used "BC/BCE" and it stayed like that for years. The thread: Talk:Religious perspectives on Jesus#BC BCE AD CE. Thanks! — Preceding unsigned comment added by Masterhatch (talk • contribs)

MOS:ERA applies so status quo ante should apply. (FWIW, Judaism and Islam have religious perspectives on Jesus of Nazareth, so the neutral style seems entirely appropriate.). --𝕁𝕄𝔽 (talk) 00:18, 22 December 2024 (UTC)[reply]

Agreed on the last part. As for the procedural matters, all of our MOS:VAR principles ultimately default/fallback to the style used in the first non-stub version that used one of the competing styles, if consensus fails. MOS:STYLEVAR is the general principle, the root rule: Don't change from one acceptable style without a very good reason. If there is or you expect resistance, discuss to establish consensus. If you don't get consensus for your change (i.e., there is consensus against you), it stays the status quo ante. If there's no consensus on which would be better (which is often the case and likely the one in this case), then use the version established earliest. For particular things covered by MOS:DATEVAR, MOS:ERA, MOS:ENGVAR, WP:CITEVAR, we simply reiterate this principle and process more topically, and these ones also basically resolve to an additional rule: don't change that particular kind of style without establishing consensus first even if you're sure you've got a good reason and don't think there should be resistance.

The STYLEVAR process actually sometimes (namely when there's clearly no firm consensus in favor of the status quo ante, either) overrides the usual Wikipedia status quo ante principle, which in practice amounts to "fall back to whatever the discussion closer thinks is more or less a pretty long-term status quo". That usually works for a lot of things, but for these "I will win my Holy Style War or die trying" tedious cyclic bikeshedding typographic disputes, it has proven unworkable, because the dispute lives on and on, simply shifting in stages to: what constitutes a status quo; how long is long enough; whether interruptions in the use of the alleged status quo have reset its tenure; whether this *VAR-imposed consensus discussion was followed when the alleged status quo was imposed; if not, then whether that imposition pre-dated STYLEVAR requiring it; and yadda yadda yadda. There's just no end to it, because it's too often a super-trivial but deeply obsessive PoV-pushing exercise grounded in prescriptivist emotions (mixed sometimes with nationalist, or socio-politically activistic, or my-profession-vs.-yours, etc.). The style-war-ending default of falling back to the first major edit that established one of the competing styles is arbitrary (in both senses), but it is the end of it, and we move on to something more productive.

For this particular article: If "it originally used 'BC/BCE'" in the original post isn't a typo, and really does mean that the style was mixed from day one, then that's a rare edge case, and JMF's "status quo ante should apply" is probably the only reasonable approach. (Even from an excessively proceduralist viewpoint: If STYLEVAR and its application ERAVAR impose an overriding principle that in this case cannot actually be applied, then the default necessarily must be the normal Wikipedian status quo ante principle, even if for matters like this it tends to lead to re-ignition of the dispute again in short order. Not every solution is perfection.)  — SMcCandlish ☏ ¢ 😼  12:02, 23 December 2024 (UTC)[reply]

But what would be the status quo ante in this case? Surely you can't mean the mixed BC/BCE style? Gawaon (talk) 08:56, 24 December 2024 (UTC)[reply]

1. Can 24-hour clock be used in articles with strong ties to United States (I have seen no US-related articles with 24-hour clock) such as: "The Super Bowl begins at 18:40 ET?
2. Can 12-hour clock be used with UTC time?
3. How are primary units of an article determined if the article has strong ties to both US and Canada, as Canada-related articles always use metric units first? For example, Great Lakes is such an article, and it currently uses imperial units first, but it would be more logical to use metric units first as a Canada-related article.
4. Why mixed units are not used with metric units? Why it is either 1.33 m or 133 cm, but never 1 m 33 cm? --40bus (talk) 23:04, 21 December 2024 (UTC)[reply]

   I'd add a fifth question: why does Wikipedia not use ISO dates, i.e. yyyy/mm/dd? They are becoming more common internationally. Skeptic2 (talk) 00:02, 22 December 2024 (UTC)[reply]

   1. I wouldn't recommend it.
   2. Probably?
   3. That should be decided on a case-by-case basis.
   4. No benefit for the additional visual or semantic complexity; that's part of the appeal of the metric system, right?
   5. English-language sources never use this format, and the English Wikipedia bases its style on that of other English-language media.

   Remsense ‥ 论 00:58, 22 December 2024 (UTC)[reply]

   You write "English-language sources never use this format", but this is untrue. ISO date format is widely used in scientific publishing and it is standard in aviation and for machine processing. Have a look at the Wikipedia entry List of date formats by country. You might be surprised.Skeptic2 (talk) 23:35, 22 December 2024 (UTC)[reply]

   I personally use ISO format on my devices; if it helps, you can replace "never" with "almost never". Remsense ‥ 论 23:36, 22 December 2024 (UTC)[reply]

1. MOS:TIME says 12 and 24 clocks are equally valid. It's just that the majority of native English speakers use 12 hour clocks, so they choose to use 12 hour clocks. If you create an article (or are the first to mention times within an existing article) then you can choose. Don't change an existing article from one to the other. With the possible exception of US Army articles, you may get kick-back from readers not familiar with the MOS. See the WP:JUSTDONTLIKEIT essay.
2. UTC is an offset. It is a separate question from how you format that time. UTC can be used with either 12 or 24 hour clocks. See MOS:TIMEZONE but it doesn't actually say much.
3. Primary units are based on strong ties to a country. If you have multiple countries with a mix of units then you have multiple weak ties and no strong ties. Therefore we default to metric first, as per WP:UNITS. Only articles with strong ties to the US and UK get to use imperial units first.
4. A major benefit of metric is that we can change from m to cm to mm to km just by shifting the decimal point. Splitting it into 1 m 33 cm makes that harder and is now rarely used in metric countries. It was more common in my country of Australia during the first 20 years after metrication when we copied our old imperial habits but it fell out of favour and we now universally say 133 cm, 1.33 m or 1330 mm as appropriate. Countries using imperial units tend to use split units because it is so hard to convert miles to feet, gallons to ounces, etc in your head.
5. ISO 8601 dates are allowed in limited cases (mostly references and tables where space is limited). It is not used in prose because it is not yet common for native English speakers to use this in their day-to-day lives. Note that any other purely numeric format is strictly disallowed. See WP:DATEFORMAT  Stepho  talk  01:09, 22 December 2024 (UTC)[reply]

   (In terms of accuracy in my own answers, 2 out of 5 ain't bad right?) Remsense ‥ 论 01:11, 22 December 2024 (UTC)[reply]

Being OCD helps 😉  Stepho  talk  01:58, 22 December 2024 (UTC)[reply]

I'm unsure how to medicalize it, but I'm certainly obsessive and compulsive, and it only helps somewhat! Remsense ‥ 论 02:00, 22 December 2024 (UTC)[reply]

Answering #2 and #4 only

• 2. No. The clarity of UTC is obtained only with a 24-hour clock.
• 4. You could write 1 m + 33 cm if you want, but why make life so complicated? The plus sign is needed because without it a multiplication is implied (1 m 33 cm = 0.33 m²).

Dondervogel 2 (talk) 07:43, 22 December 2024 (UTC)[reply]

The answer to Q2 will depend at least in part on whether UTC was chosen because it's local time or because it's the international time standard. It would make no sense to allow the 12-hour clock for events in London between March and October, but ban it for events between October and March. Kahastok talk 14:56, 22 December 2024 (UTC)[reply]

@Kahastok: I don't get this reply. The time of an events in London is given according to BST (= UTC+01:00) in summer and according to GMT (= UTC+00:00) in winter – normally without either qualification stated unless it is the weekend when the time changes. It the time zone matters (for an internationally televised live event, for example), the time is normally given both ways: in the local and in the international notations. (Or did you not realise that GMT is just another timezone, not a synonym for UTC though often used that way, especially by seafarers.) 𝕁𝕄𝔽 (talk) 15:58, 22 December 2024 (UTC)[reply]

I don't accept that UTC is always distinct from GMT. Usually there is not enough information about the reasons a particular author used one or the other abbreviation to tell if the author intended a distinction or not. Jc3s5h (talk) 17:15, 22 December 2024 (UTC)[reply]

Well OK, if we're going to insist that the sub-second formal discrepancy between GMT and UTC is somehow vitally important (despite all evidence to the contrary) the split hairs do not count in the case of Lisbon, where the local time in the winter is defined as UTC, rather than just being UTC in practice. Why would we say that a winter event in Lisbon has to use the 24-hour clock, but a summer event does not?

For the record, I don't think I have ever seen a time recorded at 17:00 GMT (17:00 UTC) and I would like to see examples of that usage. Kahastok talk 19:48, 22 December 2024 (UTC)[reply]

and you never will, because it would be pedantic in the extreme. In fact most timestamps you see anywhere will be just one of (a) not stated, because it is for local use; (b) the local timezone (notation adjusted according to whether or not DST is in operation); (c) a poor third at "front of house" (excepting worldwide online systems like Wikipedia), UTC time. Use of both (b)&(c) at once is very rare, vanishingly so if b=GMT or even BST.

Jc3s5h is certainly correct for use of GMT in almost all sources pre this century and still quite a few recently – it will take 50 years to fall out of use as a world standard, I suspect. Perhaps more ... who would think that there are still people who insist on chain (unit)s?

Just to be clear, I am not proposing that we introduce an MOS rule mandating any notation. Just clarifying that GMT is not a synonym for UTC. 𝕁𝕄𝔽 (talk) 20:25, 22 December 2024 (UTC)[reply]

If you weren't aiming to be pedantic in the extreme, why bring it up? And in particular, why claim - specifically in the context of GMT vs UTC - that the time is normally given both ways: in the local and in the international notations in situations where time zone matters? 'Kahastok' talk 21:22, 22 December 2024 (UTC) s[reply]

My 2c:

1. Not just English speakers, anybody with an analogue wristwatch display does so. BUT (in the UK at least), train, bus and plane timetables are invariably shown using 24 hour clock notation. Basically, anywhere that it matters, where ambiguity might arise.
   1. The application of am and pm to 12:00 noon and midnight seems to be a perennial source of dispute, see 12-hour clock#Confusion at noon and midnight. Good luck with writing an MOS guidance that avoids that minefield.
2. I was about to declare that UTC offsets never exceeds 12:00 so crisis, what crisis? But I think there is a UTC+13:00 on one of the Pacific islands near the date line?
3. Stepho, the use of imperial units in the UK is dying out, literally as well as metaphorically since they are preferred by the older generation. Don't be fooled by the rail-fans insistence on chains – all UK railway engineering has been done in metric since 1975. So no, MOS:RETAIN applies to UK articles too. Except articles under the aegis of Wikipedia:WikiProject UK Railways, of course. --𝕁𝕄𝔽 (talk) 15:43, 22 December 2024 (UTC)[reply]
4. I concur with Stepho's reply.
5. Anybody who puts their boiled egg upside down should be taken out and beheaded immediately! (aka, ask us again in a 100 years time but it is a non-starter right now.)

Here endeth the lesson. 𝕁𝕄𝔽 (talk) 15:40, 22 December 2024 (UTC)[reply]

You say, the use of imperial units in the UK is dying out. Is it therefore your contention that the British (or even just younger British people) all use kilometres really and just put miles on all the road signs to confuse foreigners? Kahastok talk 19:48, 22 December 2024 (UTC)[reply]

Because of the multitude of road signs and therefore the huge cost of moving from miles, that one will likely never change. In most other fields, however, there has been a progressive move toward using metric measurements in the UK over recent decades. MapReader (talk) 04:05, 23 December 2024 (UTC)[reply]

Never mind that other countries that went metric changed our road signs just fine.  Stepho  talk  05:09, 23 December 2024 (UTC)[reply]

Dondervogel 2, why must UTC be 24 hours? UTC is just a timezone. Technically it is no different any other timezone and the other time zones can use either 12 or 24 hour times as they wish. Of course, UTC is a little special in that it gets used as the "universal" timezone. And when somebody wants to be unambiguous they tend to use 24 hour time. And when they want to be really unambiguous they write it as UTC rather than local. But a lot of that is just convention. They could equally well say 4:00 pm UTC and still be very precise and unambiguous.

Also, why do you need the "+". In the 1970s in Australia (just after metrication) we used to see "1 m 33 cm" a lot. I've never seen anyone think that it was multiplication. It was more likely from the habit of doing "4 ft 7 in". Once we learnt that writing it as 1.33 m or 133 cm made conversion between them trivial (just shift the little dot), we dropped the complication of mixed units.  Stepho  talk  05:09, 23 December 2024 (UTC)[reply]

• UTC is not a time zone. It's a time standard, and it uses a 24-hour clock.
• In the language of the SI, symbols have special meanings. If you mean addition (as here) you need a "+" sign. In the absence of any other symbol, a space denotes multiplication. Outside the SI you can invent any conventions you want, and Wikipedia sometimes chooses to depart from the SI, via MOSNUM. I don't believe MOSNUM permits this particular departure.

Dondervogel 2 (talk) 08:30, 23 December 2024 (UTC)[reply]

Remsense, one reason Wikipedia can't rely on ISO 8601 throughout is that some articles express dates in the Julian calendar, or even the Roman calendar, and ISO 8601 only allows the Gregorian calendar. ISO 8601 is fine for airline schedules and hotel reservations, but it truly sucks for history. Jc3s5h (talk) 15:13, 22 December 2024 (UTC)[reply]

If we can't get Americans to switch to DMY, or Brits to switch to MDY, what hope do we have of getting both groups to switch to YMD? --Redrose64 🌹 (talk) 00:03, 23 December 2024 (UTC)[reply]

I think the biggest problem with YMD, besides unfamiliarity, is that you frequently want to suppress the Y part when it's understood, and that's harder to do when it's at the start. --Trovatore (talk) 00:14, 23 December 2024 (UTC)[reply]

I think the UN should enforce use of DMY worldwide on Mondays, Wednesdays and Fridays, MDY on Tuesdays and Thursdays, and of course dedicate the weekends to YMD. Remsense ‥ 论 00:20, 23 December 2024 (UTC)[reply]

Whaaaaat? Why would we want the least fun format on the weekend?  — SMcCandlish ☏ ¢ 😼  09:02, 23 December 2024 (UTC)[reply]

Year-first encourages us to meditate on the long term while many are less occupied at work. Remsense ‥ 论 08:59, 24 December 2024 (UTC)[reply]

My responses to these questions would be:

1. There is no strong tie of "18:40" format to the US, or the UK, or whatever. It's a format used in a variety of military, otherwise-governmental (e.g. transport/transit scheduling), and sometimes scientific and a few other contexts, and that's true inside and outside the US. It's a completely abnormal format outside of those kinds of contexts, and people don't use it on an everyday basis (that I know of; maybe there is some English-using country in which it has been so aggressively imposed that it's become an everyday norm there and people don't know what "3 pm" means any more, but I'm not aware of such a place). MOS:NUM grudgingly permits its use, but 24-hour format verges on "user-hateful" and should be avoided in most circumstances (i.e. where it's not an established norm for the subject in question).
   • On JMF's side point about "12:00 pm", MoS could easily have a rule about this, just to settle the confusion, which is common among the general populace, but not among reliable sources on time and writing, in which it virtually always corresponds to "12:00" in 24-hour time, with "12:00 am" being "00:00". MoS saying something about it, though, should be to avoid it in favor of "midnight" and "noon", because confusion among everyday people persists. (My city is gradually changing all of its "No Parking 12 AM – 6 AM, Street Cleaning, Tu, Th" signs to "No Parking 12:01 AM – 6:01 AM, Street Cleaning, Tu, Th" because of this factor).
2. Meaningless, confused question. As Stepho-wrs explained, UTC is an offset, not a format. There's a standardized way of writing the name of a UTC time-zone offset, e.g. as "UTC+05:00", but that's not relevant to how times are used or referred to (in various styles) for typical human consumption. Likewise, the Unicode name of "@" is "U+0040 @ COMMERCIAL AT", but this has no implications for use of the symbol or for plain-English references to it; writing "the at-sign" is not an error. When WP puts "3:05 pm, February 3, 2002 (UTC)" in someone's sig to conform to their date settings in the WP "Preferences" panes, that is also not an error.
   • Stepho-wrs (which surprises me, given the above) wondered why UTC offset names use a +. It's because the offsets run both directions, e.g. "UTC−05:00" is US and Canadian eastern standard time, and rendering the positive ones as "UTC 05:00" or "UTC05:00" would be problematic for humans and automation alike in various ways. The + isn't any more superfluous than the leading 0 on 00–09.
3. A Canada–US squabble over ordering: A) Who cares? We have {{convert}} for a reason. B) This is a pretty good argument (from Stepho-wrs): "If you have multiple countries with a mix of units then you have multiple weak ties and no strong ties. Therefore we default to metric first, as per WP:UNITS." B) If that argument were not persuasive, then MOS:STYLEVAR still already covers this: When there are two competing acceptable styles, do not change from one to the other without an objectively defensible reason. Try to establish consensus on the article's talk page about which should be preferred, if you are convinced a change should happen. Iff such a consensus cannot be reached, then default to whatever was used in the first post-stub version of the article (same as with ENGVAR disputes, and CITEVAR ones). So, we are not missing any rules.
4. It's "1.33 m" (not "1 m 33 cm") primarily because that is how the metric system is internationally standardized and how it is used in the real world, rather consistently. The two-units version is also less concise, and annoyingly repetitive because of how the units are named. And the system is designed to be decimal from the ground up. Thus Steoph-wrs observation: "Once we learnt that writing it as 1.33 m or 133 cm made conversion between them trivial (just shift the little dot), we dropped the complication of mixed units." It's not WP's role to treat occasionally-attestable but very disused variants away from a near universal system as if they had become norms and must at all costs be permitted. (Much of MoS's role is eliminating unhelpful variation that is confusion or which causes cyclic dispute, even if we settle on something arbitrary; but most of MOS:NUM is not arbitrary but standards-based.) As for US customary (or "imperial" units, never mind the British empire doesn't exist any longer and what's left of it metricated a long time ago), you can find decimal uses of it for various purposes in real-world publications (e.g. "0.35 in"), but it tends to be for special purposes, like establishing margin widths when printing on non-metric paper, and in electronic media when calculation or sorting might be needed. But the typical use of such units is in "3 ft 7 in" form because they are unrelated units, and because the two-unit split format is deeply conventionalized, including in various industries like construction. That's not true of "3 m 7 cm".
   • I don't buy Dondervogel_2's "multiplication implied" argument. Virtually no one outside of some particular ivory towers (and even then only in specialist material that was explicit about it) would ever interpret any "# unit1 # unit2" construction, in any context, as a multiplication operation. The real world routinely uses formats like this and never means multiplication by it. E.g. look at the fine print on any laptop's or other device's power-brick; you'll likely see back-to-back, undivided measurement-and-unit-symbol pairs, like "12 W  3.7 A".
5. Skeptic2's add-on ISO-dates question: WP doesn't use 2024-12-23 format (except for special purposes) because it is not a norm, anywhere (as an ENGVAR or other geographical or dialect consideration). It's only standardized within specific industries, systems, processes, organizations, and other specialized usage spheres. (I use it very, very frequently in web development and other coding. But it's not something I'd use in a letter or a novel or an op-ed, because it's a format for computers, and for precision and cross-language exchange among engineers and scientists, not a format for everyday communication.) I've never seen one iota of evidence of broad and increasing acceptance of ISO among the general public for daily use, in regular writing (though ability to parse it has likely increased in the last 30 years because of the Internet and the amount of people's exposure to code that uses it). But it does not match anyone but maybe an ultra-nerd's English-language parsing. If you're American, probably (unless you are older and rural) what you think and say aloud to express today's date is "December 23, 2024" or perhaps "December 23rd, 2024". If you're not American, you probably (some Canadians are an exception too) would express it as some variant of "23 December 2024", "23rd December, 2024", or "the 23rd of December, 2024", depending on your age, social background, country of origin, etc. (American yokels often use the last of those; I have relatives in the Deep South who do it habitually.) These correspond closely (between exactly and too-close-to-matter) to MOS:DATE's two "M D, YYYY and "D M YYYY" formats. An ISO date does not. It's very unnatural. It requires the reader (most readers, anyway) to stop and "translate" it in their heads, thinking about which block of numbers means what, and so on. (I've been using ISO dates on a daily basis since around 1990, and I still have to think about it a little, and once in a while get it wrong, especially shortly after transferring from narrative work to coding work.) Worse, many people do not know at all whether that represents YYYY-MM-DD or YYYY-DD-MM; lots of non-geeky non-Americans mistakenly think it's the latter because they are used to D M YYYY order otherwise, and the idea of the month coming before the day is foreign to them, an annoying Americanism. I run into this problem in a great deal of online content.

 — SMcCandlish ☏ ¢ 😼  09:02, 23 December 2024 (UTC)[reply]

Are any of these formats correct?

• a 10-cm blade
• a 10 cm blade
• a 10-cm-long blade
• a 10 cm-long blade
• a ten-cm blade
• a ten-cm long blade

And why numbers are not spelled out before unit symbols, and why unit symbols are used more with metric than imperial units, where unit names are typically written in full? --40bus (talk) 13:56, 22 December 2024 (UTC)[reply]

In answer to your first question I suggest choosing between "a 10 cm blade" and "a ten-centimetre blade".

To the second, there is no internationally accepted standard describing symbols for the imperial unit system. Perhaps that is the reason. Dondervogel 2 (talk) 14:05, 22 December 2024 (UTC)[reply]

You can also consult our {{convert}} template which deals with all these edge cases: {{convert|10|cm|adj=on|abbr=on}} produces 10 cm (3.9 in), per MOS:UNITSYMBOLS.

Also, is there a reason you're not just consulting the MOS directly? It more or less covers your questions so far. Remsense ‥ 论 15:07, 22 December 2024 (UTC)[reply]

This is possible to output: {{convert|10|cm|adj=on|abbr=on}}, and it produces: ten cm (3.9 in). So, why it is not used? And a sixth question, why fractions are not usually used with metric units? Fractions would be useful indicating repeating decimals, such as one-seventh of a meter, as things like "0.142857142857... m" or "0,142857 m" would look ugly, so 1⁄7 m would be only option. --40bus (talk) 23:13, 22 December 2024 (UTC)[reply]

Do you have a real world example illustrating your concern? Dondervogel 2 (talk) 23:22, 22 December 2024 (UTC)[reply]

How would 1⁄7 be the "only option"? You yourself just used the obvious other one: simply writing "one-seventh", which isn't broken in any way, and is probbaly easier to read for most people, than 1⁄7, which can mess with line height. It actually copy-pastes as 1⁄7, with inconsistent display on various systems. The use of the Unicode fraction-slash character is interpreted by some OSes, including my Win11 box (but not my Mac, or any Linux I can remember using), as an instruction to superscript the 1 in nearly unreadably tiny font and do the same to 7 but as a subscript. (Win11 even does this to me in a <code>...</code> block!) I'm not convinced we should have that template at all, since the Internet has done just fine with 1/7 for decades. Regarding the other material, Remsense is correct that there's a standard way of abbreviating metric units (and there's also a lot of systemic enforcement of that), but there isn't an entirely standardized approach to other units (perhaps better called "American traditional" at this point), and they are often unabbreviated in the real world. So, despite MoS providing a standard way of abbreviating them (based on ANSI or whatever, I don't remember), there's less editorial habit and desire to bother with it, while editors steeped in metric (everyone but Americans) are habituated to the short symbols. Nothing's really harmful about any of this, with regard to reader comprehension, so we have no need to firmly impose a rigid rule to do it this way or that. (We do have such a rationale for settling on particular American/"Imperial" unit abbreviations, though, since use of conflicting ones from article to article would be confusing for readers and editors alike, and some of them found "in the wild" are ambiguous and conflict with actual standards (e.g. using "m" to mean 'miles' instead of 'metres/meters'). As for the original question, yes it's "a 10 cm blade", and the output of {{convert}} is MOS:NUM-compliant. A construction like this is taken as an strongly conventionalized exception to the MOS:HYPHEN rule of hyphenating compound modifiers (writing "a 10 cm-blade" or "a 10-cm-blade" isn't really any clearer, and probably less so). In long form it would be "a ten-centimetre-long blade" and Dondervogel is correct that "-long" would usually be omitted for concision, unless it was necessary to indicate length versus width of something (which isn't the case with a knife or sword or whatnot, but would be with a shipping box).  — SMcCandlish ☏ ¢ 😼  07:12, 23 December 2024 (UTC)[reply]