Wikipedia talk:Manual of Style/Dates and numbers

Non-base ten numbers

We currently do not have a guideline on how to write numbers that are not decimal (base 10), but hexadecimal (16), octal (8) or binary (2), to name the most frequent different bases. Do we need one? If so, which style?

I am using 0x00 for hexdecimal code points in general, but have also seen most of x00, h00 or 00h, $00, #00, HEX00 or hex00 and 00₁₆ or ₁₆00 in Wikipedia. (Luckily not in articles I edited so far.) Subscript indices are certainly the most flexible solution, but also the most cumbersome to write, second is HEX, DEC, OCT, BIN (upper, lower or caps case) and h, d, o, b, which do not pose a problem when copied to plain text.

I usually use uppercase letters A–F (10–15) for the additional hexadecimal digits and would also use these with other bases larger than ten, if I needed to, although duodecimal (base 12) also commonly uses X (10) and # (11). Christoph Päper 8 July 2005 03:27 (UTC)

When I expanded the base (mathematics) article a while back, I used the 123₈ style because I needed that flexibility, and because it was the only non-computer way I knew. A style for that wouldn't be a bad idea - what do you think it should be? (Maybe different contexts call for different notations?) Neonumbers 8 July 2005 10:29 (UTC)

0x prefixing is "C notation". It is fairly widely used in programming languages that are (or were originally) built on C, like Perl, Python, and Java, and is often adopted in more general texts. I've used it myself in prose, but also made sure to add a note explaining the convention. Other times I just put something like "2C (hex)". Subscripts seem to be the preferred format in mathematical formulas, from what I remember reading, and I've seen them in prose, but when they appear in prose or in tables (like character code charts), it's terribly distracting, especially if it is used more than once. Someone recently tried to use a subscripted "HEX" on a bunch of code value ranges in one article I watch, and it looked horrible. Even if the subscripts were made extra small, I don't think they should be recommended in prose, ever. — mjb 8 July 2005 19:14 (UTC)

What I had in mind was, in articles about programming etc., use C notation, and in all other articles, use that subscript notation that you (mjb) advise against; but in articles that use lots of only one type of number, just say so at the beginning of the article and let that be the only notice for that article. Same goes for sections and tables. Neonumbers 9 July 2005 12:17 (UTC)

I agree. In articles in which the numbers are binary-related, use the C prefixes (0x, 0b, uhh... what is the prefix for octal?) For general descriptions of numbers, in which the base could just as easily be 12 or 37, use subscript notation of some type. - Omegatron 18:55, July 11, 2005 (UTC)

For octal it's just "0", which might be confusing. – Smyth\^talk 10:58, 12 July 2005 (UTC)[reply]

Possible addition to MoS on this topic:

For numbers not in base ten,

in computer-related articles, use the C programming language prefixes, that is, 0x for hexadecimal, 0 for octal and 0b for binary
in all other articles, use subscript notation, for example 137₉, 241₆, 2X9#₁₂

Please check that the C prefixes I wrote are correct. Any changes? Neonumbers 01:46, 14 July 2005 (UTC)[reply]

I like it. 0 for octal is pretty confusing/ambiguous, though. It's only used in a few articles, I'm sure, so maybe a note should be made on each page where it's used? - Omegatron 04:00, July 14, 2005 (UTC)

After thinking about it, I'm in favor of prefixed, lowercase ‘b’, ‘o’, ‘d’, ‘h’, where that suffices. Otherwise, which should be rare, use decimal subscripts. Use uppercase letters A–Z for d10–35, if necessary, i.e. A–F in hexadecimal. Christoph Päper 04:26, 17 July 2005 (UTC)[reply]

Unit Disagreement, MiB vs. MB

Discussion moved from the Village Pump - Omegatron 23:05, July 9, 2005 (UTC)

What unit types should be used when describing storage capacity in articles?

Multiple-byte units

Decimal
Value		Metric
1000	kB	kilobyte
1000²	MB	megabyte
1000³	GB	gigabyte
1000⁴	TB	terabyte
1000⁵	PB	petabyte
1000⁶	EB	exabyte
1000⁷	ZB	zettabyte
1000⁸	YB	yottabyte
1000⁹	RB	ronnabyte
1000¹⁰	QB	quettabyte

Binary
Value		IEC		Memory
1024	KiB	kibibyte	KB	kilobyte
1024²	MiB	mebibyte	MB	megabyte
1024³	GiB	gibibyte	GB	gigabyte
1024⁴	TiB	tebibyte	TB	terabyte
1024⁵	PiB	pebibyte	–
1024⁶	EiB	exbibyte	–
1024⁷	ZiB	zebibyte	–
1024⁸	YiB	yobibyte	–
1024⁹	–		–
1024¹⁰	–		–

Orders of magnitude of data

A problem has arisen in different related articles on whether to use the MB or MiB. Some articles have decided to stick with using MB, some have chosen to use MiB.

Talk:PlayStation_3#Memory_prefixes

Talk:Xbox_360#Mib_v._MB

What is the difference?

MB uses the SI decimal (base ten) system, but computers use 1 or 0, a binary (base two) system. Binary 2^10 (1024) is almost equal to the decimal 10^3 (1 000) so early on 1024 bytes was referred to as a kilobyte. This is only a 2.4% difference; however at larger scales, such as exabytes, the difference is near 20%. Depending on what computer component is being talked about MB may mean 1,000,000 bytes or 1,048,576 bytes.

http://physics.nist.gov/cuu/Units/binary.html

http://www.iec.ch/zone/si/si_bytes.htm

http://en.wikipedia.org/wiki/Mebibyte

Argument in favor of KB, MB, GB.

Manufacturers usually post system specifications using these terms.
These terms are generally understood by computer professionals as to what MB is being used.
Consumers are more familiar with MB and would be confused by other terms.

Argument if favor of KiB, MiB, GiB.

MiB is a recognized standard and technically the correct term to use.
MiB can reduce confusion as it explicitly states whether binary or decimal capacities are being discussed.
MiB is gaining more acceptance and over time will be a more familiar term.

The above is brought to us by User:Thax, who forgot to sign.

Personally, I prefer to use the more familiar MB (NIST be damned :-). That said, you might consider using the approach often used with the also ambiguous billion, which would be to add (10⁶ bytes) or (2²⁰ bytes) following the first usage depending on which is intended. Dragons flight July 7, 2005 22:02 (UTC)

Thank you for your speedy response. Do you think that it would be something worth putting to a vote? Do you think enough people even care about this issue? --Thax 8 July 2005 03:05 (UTC)

No, nobody cares, and anyway the result would be that we should go with MB but change things when (and IF) MiB becomes more common. Until I saw this writeup I didn't even KNOW this MiB existed. That is a significant thing, considering I've been downloading from the internet since 1996. But let's look at the figures shall we? Googles I mean, of course... :)

MB: 86,300,000 >> MiB: 2,580,000
KB: 60,700,000 >>> KiB: 1,070,000
GB: 37,900,000 >>> GiB: 1,140,000

Looks like the i loses. By at least a whole digit or more. Master Thief Garrett^Talk 8 July 2005 08:15 (UTC)

The only reason anyone might care is if they already know the difference. What is important is reporting the actual capacity accurately, and where necessary pointing out whether the manufacturer's labelling is inaccurate and/or misleading. The best idea would likely be to quote the manufacturer's specifications exactly and annotate this with a more accurate figure if you have it to hand.

A big reason for confusion is that sometimes the decimal and binary multipliers are mixed up: an example would be mis-stating a megabyte as 1,000 kilobytes: if you then move onward towards gigabytes the error can be compounded. Trying to determine how many bytes a given storage device might be capable of storing can be an exercise in frustration.

HTH HAND —Phil | Talk July 8, 2005 09:27 (UTC)

Note that SI symbols are case sensitive. Prefixes up to 'k' are lower case. Prefixes for 'M' and beyond are UPPER CASE. Thus 'kB' not 'KB'. Similarly, 'km' and 'kg', not 'Km' and 'Kg'. Bobblewik (talk) 8 July 2005 12:45 (UTC)

"No, nobody cares"

Oh yes we do. ;-)

Standards and accuracy are more important than tradition. We aren't going to start using feet instead of meters just because it gets more Google hits.

I say we use the IEC prefixes, and when using the SI prefixes, it should be mentioned which way they are being used, since they are ambiguous.

Related policies: Wikipedia:Manual of Style (dates and numbers)#Style for numbers.2C weights.2C and measures - Omegatron July 8, 2005 13:05 (UTC)

Good point about caring. I care too. Note that SI prefixes are not ambiguous. SI is just about the only thing in the world of units that we all agree has just one meaning. Our uncertainty when reading memory size specifications is not due to ambiguity in SI. It is due to some people to using prefixes incorrectly. Bobblewik (talk) 8 July 2005 13:34 (UTC)

Correction, accuracy is more important than both tradition and standards. However, I don't think this is something that needs to be decided as a policy one way or the other. Nine point nine times out of ten, "kilobyte" will be used with the binary meaning, and this is well enough established that confusion is unlikely. On the other hand, there's no point in going around changing articles that use "kibibyte", since those who have never heard of it can simply look it up in the nearest available encyclopedia. :)

If there is to be a policy, I suggest that it's the same one as with US/UK spelling: be consistent within an article, but respect the original author's choice, and don't change an entire article just for the sake of changing. Only if there is a real risk of confusion (as with words meaning different things in the US/UK), is an explicit definition needed. – Smyth\^talk 8 July 2005 13:52 (UTC)

Ehhhhhhh. It's not the same as spelling. Everyone knows that center = centre. Not everyone knows that a CD MB (1,048,576) and a DVD MB (1,000,000) are different. I agree that accuracy > standards > tradition. Standards and accuracy go hand-in-hand, though. ~~I would much prefer "unless otherwise noted, kB in the Wikipedia means 1000 bytes",~~ but if you want to go through and add "(decimal meaning)"/"(binary meaning)" after every instance of the word "KB" to maintain accuracy, go for it. - Omegatron July 8, 2005 14:21 (UTC)

Omegatron, that's not very realistic. - Omegatron

A CD MB and a DVD MB are the same. If you're comparing the capacities of the discs directly then you have to use one or the other. It's just that the discs differ in which one is traditionally used to give capacities. As for "unless otherwise noted, kB in the Wikipedia means 1000 bytes", well that is surely a false statement right now, and would require a vast amount of work to make it true, and a continuous patrol to correct those who weren't aware of it. – Smyth\^talk 8 July 2005 14:30 (UTC)

The main problem that I noticed isn't due to the number of articles that use one term or the other, but rather the unit disagreement on related articles managed by different people. For example in the PS3 page the talk decision was made to use MiB, but on the xbox 360 page the decision was made to use MB. For every new page that someone may want to convert to the technically correct term there needs to be a large discussion started on the merits and pitfalls of using one unit or the other. Making the decision on one location would help speed up this process and bring consistancy to related articles. --Thax 8 July 2005 16:05 (UTC)

Well I've already put my two cents in on the PlayStation 3 talk page. I think it's fallacy to say "stick with tradition until more people start using correct terms" because by that line of reasoning, we'll be incorrectly applying SI prefixes for decades to come. Why not start now? Most readers will simply ignore the 'i' in 'KiB', 'MiB', etc and read 'KB' and 'MB', respectively. Those that do notice the difference enough to wonder what it means can click the wikilink and, *gasp* learn something new (whenever I use IEC binary prefixes, I link their first instance to the article explaining their usage). I've obviously made a fuss about keeping IEC binary prefixes on some pages I watch, but only because I really believe we should all be moving towards the technically correct prefixes now that they are standardized, and what better place to start than an encyclopedia? -- uberpenguin July 8, 2005 15:13 (UTC)

It seems logical to me that if MiB is here to stay in some articles, since it is the technically correct term to use it would not be possible to make a policy decision to choose MB or MiB on all cases. For example there may be articles where the capacities discussion is very importance and needs to use MiB and MB to be specific.

Therefore it seems to me that there are the following choices:

1. The use of MiB is required in all articles.

2. The use of MiB is recommended in all articles.

3. The use of MiB or MB should be decided on a page by page basis. (No policy)--Thax 8 July 2005 16:13 (UTC)

It seems that what got this whole discussion started in the first place is that many people object to changing MB to MiB in existing articles, on the grounds that it's too obscure. They have a point. However, if, as you say, the exact capacity is important and there's any chance of confusion, then MiB is probably preferable. This does not mean that MB would then be declared to always mean 10^6. The decimal meaning is so rare that its use should always be explicitly declared. – Smyth\^talk 8 July 2005 16:19 (UTC)

Agreed, I don't think that the MB should be declared to always mean 10^6, that would be wrong. The main point of the policy decision would allow people to fix related articles to use the same units without needing to duke it out in the discussion page. My guess would be that the decimal meaning happens about 50% of the time, for example Hard Drives use the decimal meaning, while memory uses the binary meaning.--Thax 8 July 2005 16:47 (UTC)

That's all well and good but it still doesn't address what should happen when some editor changes correct MiB references to MB due to personal preference, and other authors (such as myself) wish to leave the references with the binary prefixes for their own valid reasons. Should this just go on being resolved on a case-by-case basis. If so this will surely continue to come up until eventually a heated argument will cause some case to go to arbitration when two parties can't reach an agreement. I thought it would be nice to try and at least set some loose guidelines on the usage of the SI vs IEC binary prefixes for data capacities... -- uberpenguin July 8, 2005 17:15 (UTC)

I agree with this as well. Personally I think that MiB should be a recommended option, this approach seems to work best for all parties involved.

The use of the binary prefixes, such as MiB, shall be preferred over ambiguous SI decimal references. The use of the new binary prefix standards are not required but are recommended for use on all articles where binary capacities are used. If a contributor changes an article with a binary capacity reference to use the more accurate binary system, that change should be accepted over an ambiguous application of the SI decimal system.

Does this sit well with everyone, or do we need to put this to a vote?--Thax 8 July 2005 18:27 (UTC)

That's a good idea. Instead of voting, someone start a proposed policy page, stick a {{proposed}} tag on it, start linking to it every time you change a unit, and it will evolve until we get a consensus and it becomes a guideline.

I don't see what's wrong with linking every instance of MiB. It's not terribly distracting. - Omegatron July 8, 2005 19:23 (UTC)

Agreed on both counts. – Smyth\^talk 8 July 2005 19:39 (UTC)

I may just be out in left field on this, but I would rather not be in the position of saying that MiB is "preferred". I would rather distinguish between cases where the technical distinction is important and cases where the usage is incidental. For example, an article of CD-ROM format specifications, were such to exist, clearly cares about MiB vs. MB. Whereas an article on computer simulated cosmology doesn't really care whether the simulation occupied 1 TB or 1 TiB. The latter, even if technically correct, distracts from the flow by presenting a term unfamiliar to most English readers in a context where it is basically irrelevant. Also, this doesn't address what to do with storage capacities that really are 10⁶ bytes. Obviously we can't define 1 MB = 10⁶ bytes since the real world doesn't consistently use it that way. So, should we start talking about 0.96 MiB? And what about the even more awful 1,024,000 bytes? I would propose instead a guideline to read something like the following:

In most circustances, the common english designations kB, MB, GB, etc. should be preferred if the precise specification is unknown or is largely irrelevant to the reader's understanding the article.
- Examples include:
  1. The capacity of a particular computer model when used in articles only incidentally mentioning that model's result.
  2. Estimates of the amount of information collected by the spy satellites each day.
In cases where the precise specifications are known, but are likely to be of interest to only a few readers, rather than most, editors are encouraged to parenthetically write out the intended meaning the first time it is used: e.g. "4 MB (4*10⁶ bytes)" or "4 MB (4*2²⁰ bytes)" or "4 MB (4,096,000 bytes)". In this case, it may also be appropriate to write "4 MiB (4*2²⁰ bytes)", if the device's storage capacity is routinely expressed as a multiple of a binary power.
- Examples include:
  1. The storage capacity of most consumer electronic devices, unless data storage is a major part of the discussion.
  2. The size of most software packages.
Lastly, technical articles, where the precise number of bytes is likely to be of interest to most readers, are encouraged to use KiB, MiB, GiB, etc. throughout.
- Examples include:
  1. Detailed discussions of storage formats or compression algorithms.
  2. Discussions of devices focusing on storage capacity or comparing storage capacity between many similar devices.

I don't expect that everyone will agree with this, but this summarizes how I would want to approach the problem. Dragons flight July 8, 2005 21:27 (UTC)

I like it. – Smyth\^talk 8 July 2005 21:52 (UTC)

What's wrong with listing something as MB or MiB? If you want to know what the value is, follow the link. The link should make things clear, right? Vegaswikian 8 July 2005 21:56 (UTC)

MiB is always clear, but MB never is since industry groups use it interchangably to mean either 1,000,000 bytes, 2^20 = 1,048,576 bytes, or 1,024,000 bytes. Dragons flight July 8, 2005 22:11 (UTC)

Okay I tried to summarize everyones ideas and viewpoints the best I could at Wikipedia:Manual of Style (dates and numbers)#Binary unit prefixes. Please tweak it as required. If it is in the wrong place please move it, I am a newb and just trying my best at doing the right thing. What should we do with this discussion, is it bad etiquette to copy and paste everyones comments to a different location? --Thax 20:02, 9 July 2005 (UTC)[reply]

It is ok to move discussions; especially from the Village Pump, where they will be archived (effectively deleted) after a short time period.

I moved it here. - Omegatron 23:05, July 9, 2005 (UTC)

Such changes are meant to get consensus before being published on a project page, that means voting unless clearly everyone in the discussion is thinking exactly the same thing. I didn't really see much of a consensus there; correct me if I'm wrong. So if there isn't one clear consensus (or it is evident that consensus will never be reached), that section shouldn't be there at all - yet. Neonumbers 10:56, 10 July 2005 (UTC)[reply]

We must not imply that SI prefixes are ambiguous. They are not ambiguous. SI was specifically created to eliminate ambiguity in unit terminology. It is about the most unambiguous thing that anyone in the world can use with respect to units. People may use SI prefixes incorrectly, but that does not mean that SI prefixes have more than one definition.

For example, the phrase the SI prefix was used in a binary sense implies that SI prefixes have more than one interpretation. Similarly, the MiB reference is less ambiguous implies that SI prefixes are more ambiguous.

Apart from that, I welcome the attention that is being paid to this issue. Bobblewik (talk) 11:31, 10 July 2005 (UTC)[reply]

I'm sorry, but "MB" is somewhat ambiguous in a way that "MiB" is not. Yes, from an official point of view, using M to mean 2^20 is utterly and totally incorrect, but from a neutral point of view that is exactly what people do, and calling an overwhelmingly common use "incorrect" is being pedantic. Look at Nucular – I was shocked when I saw it, but language changes, whether we want it to or not. – Smyth\^talk 12:52, 10 July 2005 (UTC)[reply]

I disagree. Language changes, but measurements, units, and SI prefixes are not language. We're not going to redefine the definition of the meter so that the speed of light works out to exactly 3×10⁸, just because everyone says it that way. - Omegatron 13:07, July 10, 2005 (UTC)

Your speed of light example is totally off-base. It is, in fact, correct to say, when you include the units, that the speed of light is 3×10⁸ m. Not only that, but it is also correct to say that the speed of light is 3.0×10⁸ m or 3.00times;10⁸ m. That number is accurate to three significant digits and then some, with a relative error of one part in 1444. In other words, it isn't a "different" number, it is simply the same number expressed to less precision. Gene Nygaard 13:39, 10 July 2005 (UTC)[reply]

If someone says the speed of light is 3×10^8 m/s, they know they are making an approximation. If they say a CD has a capacity of 702 MB, they know what they mean by "M", and it's not 1,000,000. The prefixes are part of the language of the computer world, but of course I'm not suggesting that SI prefixes in general are ambiguous. This is just a special case. – Smyth\^talk 13:16, 10 July 2005 (UTC)[reply]

I agree that binary prefixes are not misused as much as SI prefixes. So if I see '2 MiB', I may be more certain about what the author meant than if I see '2 MB'. I agree that we should highlight the uncertainty. It is definitely worth mentioning ambiguity and uncertainty. I merely want to avoid using phrases that attribute ambiguity and uncertainty to the SI standard itself. This can be achieved easily by a slight change in wording. Bobblewik (talk) 13:45, 10 July 2005 (UTC)[reply]

What I'm saying is that language evolves and changes due to common usage. Defined concepts and quantities don't. Just because everyone uses "power" and "energy" interchangeably doesn't mean that power is no longer the rate of change of energy; the words are simply being used incorrectly.

"If someone says the speed of light is 3×10^8 m/s, they know they are making an approximation."

Not necessarily.

"they know what they mean by "M", and it's not 1,000,000."

Not necessarily. - Omegatron 15:30, July 10, 2005 (UTC)

Concepts remain unchanged, but words used for them often gain new meanings. Anyone trying to understand a physics paper without knowing what physicists mean by "power" and "energy" will be confused. Anyone trying to understand the specification of a RAM chip without knowing what computer people mean by "kilo" and "mega" in different contexts will be similarly confused. Anyway, this is getting away from the original question, which is:

Should people object to "MB" being changed to "MiB", where the latter is factually correct?

The only people who have objected so far have done so either because "MiB" is too obscure (fixed by a simple wikilink), or becaue Microsoft/Sony/whoever did not use the IEC terminology in their own documents, which I don't think is of any relevance to us. – Smyth\^talk 17:37, 10 July 2005 (UTC)[reply]

Agreed, those are only objections I have noted this far as well, with the exception of people who may not understand the proper application of the binary units. I think most objections initially start because people are unfamiliar with the term and prefer to stick with what they are personally familiar with. --Thax 03:33, 11 July 2005 (UTC)[reply]

FWIW, I think the arguments for MB at the start of this discussion have more merit. It's the unit used by the manufacturers and therefore the most used term and the most understood by laymen. Two arguments specifically mentioned in the WP naming conventions. - Mgm|^(talk) 08:49, July 11, 2005 (UTC)

"Nine point nine times out of ten, "kilobyte" will be used with the binary meaning"

"The decimal meaning is so rare that its use should always be explicitly declared."

I disagree. Talk:Binary prefix#Various_references has clearly established that proper use of SI prefixes to express decimal capacities is more prevalent than binary. There are only 3 main offenders: RAM capacities, CD capacities, capacities reported by OS (Windows in particular). The last one creating most problems. Delicates 13:31, 11 July 2005 (UTC)[reply]

For "OS" read "virtually every program on any operating system that describes byte sizes". If we're going to talk about what the average user will be familiar with, that's a fairly important fact. And I don't know why you pick out Windows; on Linux, ls, dd and du all use binary multiples. As is conventional, iptables uses decimal multiples when counting packets or bytes, but higher-level networking programs like web browsers or p2p clients will use binary multiples on all platforms. – Smyth\^talk 14:12, 11 July 2005 (UTC)[reply]

I thought I heard the Linux kernel switched to IEC prefixes... - Omegatron 14:55, July 11, 2005 (UTC)

I don't know where the kernel would have need to use any prefixes at all. Anywhere it presents a number, the number is probably unabbreviated. – Smyth\^talk 14:04, 12 July 2005 (UTC)[reply]

Hmm.. I don't know. This is all I have to go on:

"After a much heated discussion in December 2001 on linux‐kernel mailing list, the binary prefixes have been accepted by key Linux developers, and are now extensively gaining ground across Open Source UNIX applications." [1]

Developer discussion here

I love how computer people say that kibi- is "ugly" or "sounds funny" after coming up with units like "byte" and "nibble". - Omegatron 14:32, July 12, 2005 (UTC)

For what it's worth, the Linux kernel is not consistent at all: in the boot log alone you will find "Kbytes", "kB", and "k". There's bound to be Kib somewhere as well. Rl 14:35, 12 July 2005 (UTC)[reply]

This reminds me of the AD/CE dispute last month. Like it or not, similar to AD, Kb is the most widely used and most widely understood term. Similar to CE, Kib is a well-intenioned attempt that has failed to displace the common meme. The average person will know what a kilobyte is by now, but will look strangely at a kibibyte. R adiant _>|< 11:26, July 12, 2005 (UTC)

But "KB" doesn't endorse a Christian POV. :-) - Omegatron 13:19, July 12, 2005 (UTC)

Vote

The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts

Proposed wording: as it is currently worded (July 9, 2005). (The current wording allows some flexibility "The use of the new binary prefix standards in the Wikipedia is not required, but is recommended" ... "but you can change 512 MB RAM to 512 MiB RAM where it is important to do so.")

Omegatron 16:00, July 12, 2005 (UTC) - This article sums up my opinion perfectly: A plea for sanity.
On the Wikipedia, accuracy is more important than "common usage" (which isn't really common usage, anyway, outside of computer science classrooms.)
Even in instances where the units are referring to an approximation, I think the appropriate unit should be used. ("...memory chips in the hundreds of mebibytes...", "...archives use several TB of disk space...")
Pmsyyz 15:42, 12 July 2005 (UTC)[reply]
Delicates 16:00, 12 July 2005 (UTC)[reply]
Urhixidur 16:09, 2005 July 12 (UTC)
Dpbsmith (talk) 16:28, 12 July 2005 (UTC). The issue, as always, should be serving the reader. Because the "traditional" nomenclature is ambiguous, using only the "traditional" nomenclature never serves the reader well. Leave it up to the discretion of the writer as to whether the terms should be briefly explained on their first appearance within an article, and whether there is any need to provide equivalents in decimal-based units. And, Emerson, foolish consistency, etc. As with British versus American usage there is virtue to consistency within any single article but no compelling need for consistency throughout Wikipedia. It is safe to assume that our target audience includes readers who are both familiar and unfamiliar with the IEC prefixes, and also that our target audience should not have any difficulty understanding the IEC prefixes if they are explained or linked on first occurrence. Dpbsmith (talk) 16:28, 12 July 2005 (UTC)[reply]
Thue | talk 16:42, 12 July 2005 (UTC)[reply]
Thax 16:44, 12 July 2005 (UTC)[reply]
Dragons flight 16:56, July 12, 2005 (UTC) Changing vote. I had misunderstood what was meant by "all appropriate". The current wording seems to be a reasonable compromise, though I would still like something to the effect of "if you don't know or the reader couldn't possibly care, stick with MB, etc."
- "Appropriate" was a bad wording, sorry. I have changed it to "binary-multiple", since I trust that's how most people understood it, and it is what the current wording says. – Smyth\^talk 17:32, 12 July 2005 (UTC)[reply]
Grahn 17:16, 12 July 2005 (UTC)[reply]
Cburnett 19:29, July 12, 2005 (UTC)
Seems fine as long as the wording is not too strong. Gdr 22:44, 12 July 2005 (UTC)[reply]
uberpenguin 01:33, July 13, 2005 (UTC) My opinions are already obvious here, but I'm adding my name for posterity. Just acknowledging that there exists an ambiguity problem isn't sufficient; we need to do something about it rather than just sitting back and resigning ourselves to ignoring the problem until it comes up again. I think the wording should also at least mention the usage of the older term "Kiloword," "Megaword," etc, when referencing (mostly older) computers that did not use an octet byte as the base memory unit. Here again, the IEC binary prefix should be recommended but not required ONLY if it is appropriate (since there are plenty of circumstances when the SI interpretation of "Megaword" -- 10^6 words -- is the correct one).
Lachatdelarue (talk) 14:14, 13 July 2005 (UTC)[reply]
Weejee 03:45, 14 July 2005 (UTC)[reply]
The binary prefixes have for the past 3-5 years shown up in computer science courses world-wide and can be expected to find their way into common industry use as more new students graduate. Wikipedia can easily adopt new and sensible terminology, because an explanation of what it means is just a click away. It is ridiculous, on the other hand, to confront readers with a convention that says that 1 kbit = 1024 bit whereas 1 kbit/s = 1000 bit/s. Markus Kuhn 15:52, 14 July 2005 (UTC)[reply]
D. F. Schmidt (talk) 18:32, 15 July 2005 (UTC) I feel that it shouldn't matter whether something is rendered in MB (10⁶) units or (2²⁰) units. The difference is slightly less than 5%. (For gigabytes, the difference is 7.37%) This should be inconsequential to anyone reading this encyclopedia. For one, if someone studies enough, they'll figure out this discrepancy sooner or later, and when they think about it long enough, they'll determine that this whole thing is moot. Why bother caring about it? The SI fan in me remembers the calorie/kilocalorie problem, but this also is inconsequential, because the term used on food product packaging is the only one used on food product packaging. Thus, it doesn't matter if a computer product says '1 GB,' and the actual computer renders that as $10^{9}$ or ${\frac {10^{9}}{2^{30}}}=0.931\;10^{9}$ . There are at least two reasons for this: the customer cannot do anything about it, and the manufacturer is not willing to do anything about it. But in the interests of science and precision, it should be a policy that base-10 prefixes and base-2 prefixes should be used where applicable.[reply]
Bobblewik (talk) 18:51, 15 July 2005 (UTC)[reply]
Dwheeler Where a specific value for a base-2 multiple is given, you should always use the binary prefixes: MiB, GiB, etc. Where a base-10 multiple is used, or no precision is intended, use the base-10 prefixes, e.g., "many megabytes". Many Americans don't routinely use metric, so the SI prefixes may be less familiar to them, but everyone else "knows" that a kilo is a thousand, a "Mega" is 1.000.000, and so on. The "1.44Mbyte floppy" mixes the binary and decimal units, and transmissions in bytes are often measured where megabytes=1.000.000bytes, so even with bytes the prefixes' meanings are starting to go back to being exclusively decimal prefixes as they were originally intended. As computer hardware becomes more capable the inaccuracies are getting larger. Finally we have an accurate way of expressing these values; we should use them. I'm already seeing MiB in many other places, and there's no reason for Wikipedia to lag behind.
Christoph Päper 04:30, 17 July 2005 (UTC) Everything else is just stupid (as wiki-voting is). Most people will just ignore the i for now.[reply]
WLD 22:32, 17 July 2005 (UTC)[reply]

The MoS should encourage the use of the IEC prefixes only in highly technical contexts

Proposed wording: first two paragraphs as at present, followed by:

However, the IEC prefixes are still relatively obscure and should not be used in general-interest articles. It is not necessary to expand every use of the SI prefixes if they are only being used approximately, but if the exact value is at all significant then it should be identified explicitly, like this:

"... 512 MB (536,870,912 bytes) of RAM, and a 40 GB (40,000,000,000 byte) hard drive."

The IEC prefixes should only be used in highly technical articles where binary multiples are used exclusively, such as Random access memory. On their first appearance, they should be adorned with links to their corresponding articles, like this:

"A 512 MiB memory module"

– Smyth\^talk 13:58, 12 July 2005 (UTC)[reply]

Dragons flight 16:07, July 12, 2005 (UTC) As per comments above, the use of unfamiliar (even if technically correct) terminology is a distraction in many contexts where the distinction is utterly irrelevant to the readers understanding. I would prefer however that "highly technical" be changed to "technical" and "should only be used" to "are recommended to be used", more flexibility is better.

The MoS should discourage the use of IEC prefixes anywhere

Proposed wording:

However, the IEC prefixes are obscure and should not be used if possible. It is not necessary to expand every use of the SI prefixes if they are only being used approximately, but if the exact value is especially significant then it should be identified explicitly, like this:

"... 40 GB (40,000,000,000 byte) hard drive."

Support The prefixes are useless, and there's no line between general interest and technical articles. --Dtcdthingy 17:25, 12 July 2005 (UTC)[reply]
Support Wikipedia is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering.
Ben Arnold 21:41, 12 July 2005 (UTC)[reply]
Support As taught in most universities comp sci departments and as understood by programmers, a kilobyte is understood to be 1024 bytes, as the user above pointed out. --kudz75 00:20, 13 July 2005 (UTC)[reply]
Support This seems to be a meaningless topical discussion like arguing if Pluto is a planet. The IEC is trying to make a mountain out of a mole hill here, and chaning terminology is something that should have been done back in the 1950's, not 1990's. Marketing gurus are the real idiots who have mistaken MB to mean 10⁶ anyway, as most real software and computer engineers have no problem with MB == 2²⁰ (1,048,576) and GB == 2³⁰. This mainly is because a marketing idiot who suddenly discovers that a 40 GB drive (40 x 2³⁰ = 42949672960) can be marketed as a 43 GB drive, and not 40 GB, to try and make it seem their product is somehow better than a competitors. From my experience, even hard-core developers who really do development work don't really care about semantic discussions anyway, except for a few purists. --Robert Horning 11:01, 13 July 2005 (UTC)[reply]
The standard's not established enough yet. I had never heard of these things before I came to Wikipedia. Neonumbers 11:21, 13 July 2005 (UTC)[reply]
...and I had never heard of these things before it was raised on the Pump, and I've been downloading countless gigs of who-knows-what since 1996. Come back in 2008 when it's an accepted term, or, rather, at which point it's stagnated. Oh, Support, as if it wasn't obvious. :) Garrett^Talk 03:22, 16 July 2005 (UTC)[reply]

The MoS should not mention this issue at all

No more stupid votes

Voting is not what consensus is about. I'm sick to death of votes being started left and right. m:Polls are evil. -- Cyrius|✎ 23:06, 12 July 2005 (UTC)[reply]
Hear hear. — David Remahl 10:36, 13 July 2005 (UTC)[reply]

The Wikipedia should only represent common usage

This is ridiculous. There are a few extremely important points that are being ignored here. First, and most importantly, The Manual of Style should reflect common usage on Wikipedia, and not prescribe a usage which is not the common usage'. So no matter if 3 or 5 people vote here that the MoS should "recommend" the IEC prefixes, if that usage is no the common usage on Wikipedia, then it shouldn't be in the MoS. The reality is that the IEC prefixes are extremly obscure, particularly to the lay reader. Second, "oh, we'll just put in a link" is not really an adequate response to that complain. It's not a valid argument for the same reason that many articles include measurements in feet in inches. Third, people are used to kilobytes being 1024 bytes and megabytes being 1024 kilobytes, and even though there are new prefixes that define that explicitly, those prefixes do not enjoy common usage. It doesn't matter if they're official (whatever that means--there is no regulatory authority over the English language). The only thing that matters is common English usage—and with the exception of hard disk manufacturers and a few others, a megabyte almost always means exactly 1,048,567 bytes [2]. Usage on Wikipedia should reflect the common usage, and the MoS should reflect usage on Wikipedia. Nohat 23:24, 12 July 2005 (UTC)[reply]

If a styleguide or manual of style was just to reflect common usage, it would be pretty much unnecessary. It reflects best usage. It's about shoulds, not ares, mays or cans, but neither musts. Even (or especially) anarchy needs some ground rules. Christoph Päper 04:37, 17 July 2005 (UTC)[reply]

But that's not true. We've been through this before on other talk pages. 1024-bit kilobits are not an overwhelming majority usage. Depends on what field you're talking about.

"The reality is that the IEC prefixes are extremly obscure, particularly to the lay reader."

kilobyte = 1024 bytes is obscure to the lay reader.

Not to anyone who's bothered to look it up in the dictionary, which all give 1024 bytes as the primary if not the only meaning. [3] [4], also the Oxford American Dictionary. Nohat 06:05, 13 July 2005 (UTC)[reply]

"Oh, we'll just put in a link" is not really an adequate response to that complain[t].

And believe it or not, this usage is not consistent at all. I searched each of the bolded words, and here are their first hits:

"Technically, therefore, a kilobyte is 1,024 bytes, but it is often used loosely as a synonym for 1,000 bytes."[5]
" In data communications, a kilobit is a thousand (103) bits." [6]
"In the U.S., Kbps stands for kilobits per second (thousands of bits per second)" [7]
" In data communications, a megabit is a million binary pulses, or 1,000,000 (that is, 106) pulses (or "bits")." [8]
"When used to describe data storage, 1,048,576 (2 to the 20th power) bytes. Megabyte is frequently abbreviated as M or MB. (2) When used to describe data transfer rates, as in MBps, it refers to one million bytes. " [9]
"Fast Ethernet to 1000 Mbps, or 1 gigabit per second (Gbps)" [10]

Just because you've never heard of something doesn't mean that it doesn't exist. - Omegatron 12:45, July 13, 2005 (UTC)

Part of the reason for those distinctions is that once you throw in seconds, it is no longer a counted quantity but rather a measured quantity. The binary progression disappears when you add a time factor. Gene Nygaard 12:55, 13 July 2005 (UTC)[reply]

Yes. And the binary progression is not even there in the first place for things like disk media - CDs, DVDs, hard drives are all based on cylinders and frames and sectors, not powers of 2.

Actually, memory is really the only thing that is implicitly binary. Bus speeds, clock cycles per calculation, storage sizes, clock rates, communications rates, calculations per second, and everything else are measured, decimal quantities. - Omegatron 13:38, July 13, 2005 (UTC)

And it's not just hard drive manufacturers. Why does everyone always say that? I guess they felt ripped off the first time they bought a hard drive and vowed to never forgive the conspirators. :-)

More Wikipedians probably say "aluminum" than "aluminium" (Americans), but we stick to the recognized standard when there is one. - Omegatron 23:41, July 12, 2005 (UTC)

No, no, no. The vast majority of times that most people interact with measurements of bytes is every day while they're using their computer looking at directory listings or properties dialogs containing file sizes or measures of free space. We're talking about at least 99% of the times that people deal with any kind of measurement in bytes, if not dramatically more. Perhaps in certain subfields people use the powers of 10 meanings, but the number of people for whom the power of 10 meaning is the most salient is vanishingly small. The rest of the world, ordinary people who are just using their computers, deal with the capacity of hard disks or CD-ROMs or DVDs or flash devices or whatever many orders of magnitude less frequently than they deal with the actual size of files or free space, which is essentially invariably reported by the operating system in powers of 2.

No, it doesn't. One of the reasons this is an issue in the first place is that computer software has never consistently adhered to any particular standard in reporting RAM and disk usage. For example, in the current release of Windows XP the formatting utility refers to the capacity of floppy as "1.44MB", which is neither binary nor decimal (it is the "hybrid" megabyte = 1000 * 1024), and then the same utility, after formatting, refers to the capacity in binary megabytes. It would take some careful research to do a full historical overview of how various versions of various operating systems have handled this, but there is no well-defined, consistent, defacto usage. Dpbsmith (talk) 14:35, 13 July 2005 (UTC)[reply]

Two, the "recognized standard" argument will never fly as a justification for a policy. That's just not the way Wikipedia works. There are countless examples on Wikipedia going back years where supposed "standards" are not used because they're obscure or don't represent common usage. Just look at the policy for, say, the titles of articles about biological organisms or foreign cities or the policy for the use of various national spellings. Indeed, aluminium remains at that title NOT because the official IUPAC name is "aluminium", but because of the "use national spelling used by first major contributor to article" policy.

I didn't say it was just hard disk manufacturers ("hard disk manufacturers and a few others, but they are in fact the only significant user of those meanings of megabyte and gigabyte. But as I explained above, the vast majority of usage—by an almost incomprehensible margin—is the size of files as reported by operating systems, which is nearly invariably using the powers of 2 meanings of kilobyte, megabyte, etc. Nohat 05:56, 13 July 2005 (UTC)[reply]

"The only' thing that matters is common English usage"

Not true. Accuracy is more important than common usage. The old usage of "kilobyte" to mean both 1000 or 1024 bytes, depending on context, is hopelessly ambiguous, inaccurate, and really frustrating to both computer newcomers and computer-related developers (except comp sci majors, apparently, who are off in their own little world). - Omegatron 12:45, July 13, 2005 (UTC)

No, service to the reader is what matters. In this case, a) common usage is not all that well-define or universal. When a software job mentions a salary of "80K" it does not mean $81,920. b) Common usage is, in fact, confusing. The commonest current practice seems to be to disambiguate "MB" or "GB" by giving the actual number of bytes, e.g. "Used: 9.95 GB on disk (10,683,035,648 bytes)." This would not be necessary if MB and GB were widely understood to have binary meanings. c) Practice b is very awkward. It is convenient to have short abbreviations. d) Regardless of whether the IEC prefixes are in the process of adoption, they are very easily understood even from context. It is not appropriate to push an agenda of using something deemed technically correct or important, but it is perfectly reasonable to use the IEC abbrevations selectively in situations were the alternatives are awkward or long or clumsy or confusing. I would oppose using GiB if GB in fact had an unambiguous and universally-understood meaning. Since it does not, we need to do something besides simply using GB, and GiB seems very reasonable to me. It's short, sweet, easily understood, and has the backing of at least one standards organization. Dpbsmith (talk) 14:35, 13 July 2005 (UTC)[reply]

See Talk:Binary_prefix#Organization_recommendations for several organizations that have adopted these units. I'm sure there are more. - Omegatron 14:57, July 13, 2005 (UTC)

I'd imagine that most contexts in Wikipedia where "kilobyte", "megabyte" etc are used fall into two groups:

Inexact estimates where the binary/decimal distinction is not significant. In this case, they should be left as "KB", "MB", etc, and the current wording supports that.
Exact measurements, in technical specifications and so forth, where the distinction is significant. In this case, they should be changed to whichever of the SI or IEC prefixes makes the exposition easier, and a full expansion given if there is any chance of confusion. Such technical discussion would probably not be read by "ordinary people who are just using their computers", and even they were, "MiB" looks so similar to "MB" that they would probably skip over it without a thought. – Smyth\^talk 10:02, 13 July 2005 (UTC)[reply]

Permitting removal of metric units: inconsistency in the Manual of Style

This is what the Manual of Style says about metric units:

Metric units are always acceptable
if non-metric units are always given there is usually no need for metric units
give the metric equivalent as a courtesy
should not be used if they reduce the flow of a sentence
should not be used if they interfere with the quality of the writing
should be used where these are appropriate
multiple equivalents including metric are cumbersome and shall be avoided.

Those phrases are inconsistent, ambiguous and subjective. An editor wanting to remove metric units can claim that removal is consistent with the Manual of Style.

Some of the phrases were added without discussion. Does anybody have any proposals for different wording? Bobblewik (talk) 12:43, 11 July 2005 (UTC)[reply]

I'm thinking about this as I write, so I'm writing this on the spot. The ideas that we're trying to convey are (respectively):

Metric units should not be changed to non-metric at the expense of the metric
Some contexts will not require metric units
In others, metric units should be there, i.e. length
In sentences like, "he was miles from the station", there is no point
Same idea as the one above
I don't understand that part
Don't get too carried away with equivalents

So I think the contexts that don't require units are meant to be scientific contexts where non-metric units are normally used, like say astronomy, the AU, and imperial units that the reader will visualise as he reads should be converted to metric. Either that, or the statements are contradictory.

I was going to start writing an initial proposal for different wording here but I'm too tired to - I hope these ideas clarify things for a starter. Neonumbers 13:40, 12 July 2005 (UTC)[reply]

I don't see all of what Bobblewik does, but I do think the topic needs some reworking. Maybe before we worry about specific wording, we should try to gauge agreement on some possible principles.

Also, possibly some of the prior disagreement was based on an abundance of numbers in body text. Maybe that should be addressed. Maurreen 16:27, 12 July 2005 (UTC)[reply]

Ideally there should be a technical solution to the problem, such that each user could specify what units they want to see and wikipedia would dynamically output the correct unit. This would address all unit problems, including format issues.

You would need to be able to specify quanitity, unit type, precision, auto scale to the most appropriate unit or not (3000 mm would show as 3 m), and whether to force the display of a specific unit where it is required. <unit>\quantity {35} \unit {kg} \precision {0} \noscale</unit> --Thax 17:05, 12 July 2005 (UTC)[reply]

A technical solution will not be available. See [11] r3m0t ^talk 19:54, July 17, 2005 (UTC)

Possible principles for units and systems of measurement

Please feel free to add to this list. Maurreen 16:27, 12 July 2005 (UTC)[reply]

Broad clarity to speakers of English is a priority. Corrolaries:
1. Giving conversions to other systems is generally encouraged.
2. An exception is casual usage such as in "Their views were miles apart."
In general, there is no preference among metric, Imperial or customary U.S. units.
1. Exceptions are made for articles that focus specifically on a region or field. In those cases, measurement units typical to that region or field are preferred. (Please note that, concerning acres and the United States, this would contradict the current style for land area.)

Suggested rewrite of 'units' section in Manual of Style

My suggestion is to rewrite the entire 'units section. Here is a suggested replacement:

Wikipedia articles are intended for people anywhere in the world. Try to make articles simple to read and translate.

Metric units are permitted. This applies to all parts of all articles.
The sequence of units indicates the source value. Show the source value first.
- Show secondary units in parentheses.
- Show the secondary units in symbolic form.
- For example '100 mm (4 in) pipe for 10 miles (16 km)'. This that the source values are 100 mm and 10 miles.
Converted values should use a similar level of precision as the source value. For example, "the Moon is 400,000 km (250,000 miles) from Earth", not "(248,548.477 miles)".
Use standard symbols: metre -> 'm', kilogram -> 'kg', inch -> 'in' (not " or ″), foot -> 'ft' (not ' or ′)
Do not append an s for plurals of unit abbreviations. Thus 'kg', 'in', 'yd', 'lb' not 'kgs', 'ins', 'yds', 'lbs'.
Use a forward slash for division. Thus ft/s rather than fps.
Non-metric units often have several versions. Be specific. Thus 'US gallon' or 'imperial gallon' rather than just 'gallon'. This is particularly important in nautical and aviation articles where 'mile' is ambiguous and should be 'nautical mile' or 'statute mile'.
The reader should see a space between the value and the unit symbol: "25 kg", not "25kg".

Bobblewik (talk) 19:27, 12 July 2005 (UTC)[reply]

I disagree with « Use a forward slash for division. Thus ft/s rather than fps. ». The writing rules for SI symbols are well known, but they do not apply to the U.S. and Imperial systems. The mile per hour could be written mi/h but the traditional English abbreviation is mph, and that is what should be used. The Conversion of units table goes to great lengths to document these traditional abbreviations.

Talking about ambiguities, the statute mile (a.k.a. the U.S. Survey mile) is not the same as the "standard" mile. See Conversion of units.

Finally, the rule of space between number and symbol does not apply to the degree of temperature (°C, °F, and others) nor to the angular degree, minute and second of arc.

Urhixidur 03:38, 2005 July 13 (UTC)

ISO 31-0 and all other formal standards on SI units require a space in the temperature 20 °C, but none in the angle 90°! Markus Kuhn 16:02, 14 July 2005 (UTC)[reply]

There may be a point of contention here, since British style calls for a space between the number and the degree sign. Oxford Style Manual (2003), 7.5: "There is a space of the line (or thin space in scientific and technical work) between the figure and degree sign. . . When giving a range of temperatures, print the symbol close up to the abbreviation: 10–15°C." American style differs here, too, calling for closed up symbols to be repeated when giving a range, e.g., 10°C–15°C, 10%–15%. —Wayward 05:47, July 13, 2005 (UTC)

A "statute mile" is any 5,280 ft mile. In other words, it includes both the old U.S. definition which survives as the U.S. Survey mile, and the current international definition which is 2 parts per million shorter, at 1609.344 m.

In temperature in degrees on some scale, there is some split in authority about whether or not to use a space between the degree symbol and the number (But not exactly the U.K./U.S. distinction Wayward makes—NIST, for example, prescribes the space for degrees of temperature, unlike the spaceless degree signs for angles). As Wayward points out, one thing is clearer is that under the modern rules the degree symbol butts up to the symbol identifying the scale rather than to the number, and that something like "15° to 30°C" or "15° to 30° C" are both improper; don't use the degree symbol separate from the C or whatever. For temperatures in kelvins, there is no difference from any other units. Gene Nygaard 12:12, 13 July 2005 (UTC)[reply]

Looks fine, but after

Use a forward slash for division. Thus ft/s rather than fps.

I would put something like:

But in scientific contexts SI notation is appropriate, for example m s?2.

Gdr 23:43, 12 July 2005 (UTC)[reply]

Is that the standard way to do it? m·s?2 looks better to me. - Omegatron 23:56, July 12, 2005 (UTC)

That would be fine too. See SI#SI writing style. Gdr 00:03, 13 July 2005 (UTC)[reply]

About metric units: "Metric units are permitted. This applies to all parts of all articles." I agree with permitting metric units, but to single out metric units like this could be read as favoring metric units. Is that your intention? Maurreen 03:08, 13 July 2005 (UTC)[reply]

It certainly would be mine. There is no other system in scientific and engineering contexts, and even the U.S. and Imperial systems are defined in metric terms nowadays.

Urhixidur 03:32, 2005 July 13 (UTC)

I agree with all comments above.

I think perhaps the line about source value could be written "The first value stated should be the source value." This gets to the point in the first sentence.

And maybe in non-scientific contexts, metric and US equivalents should be encouraged? Saying they're "permitted" is a bit vague, though I realise that some contexts like to be different and so won't want equivalents - but apart from scientific articles, I can't think of any. More general knowledge (as opposed to specialised) articles will probably want equivalents.

"Use standard symbols" - does this mean that the entire word is to be avoided (in the source value), or just don't use non-standard symbols if you want to use symbols? Neonumbers 04:29, 13 July 2005 (UTC)[reply]

How about "Both metric and U.S. units are acceptable" instead of: "Metric units are permitted. This applies to all parts of all articles."

And "Avoid nonstandard symbols" instead of "Use standard symbols." Maurreen 05:34, 13 July 2005 (UTC)[reply]

There is no inconsistency in the MoS as it stands. The MoS says the following (and these points have been added to or tweaked by several editors, and appear to represent the current consensus):

1) In scientic contexts, use SI units.

2) There is no need to perform a conversion.

3) In non-science articles, editors may choose metric, U.S. customary units, or Imperial.

4) Conversions from and to any of the above may be helpful, but are not mandated.

5) Specifically, conversions should not be offered if they interfere with the quality of the writing.

6) Multiple equivalents are cumbersome and should be avoided, except for unusual units.

There is no consistency there whatsoever. What the MoS says is that editors may choose what to do in all non-science articles. Leaving the choice to editors on the page is a good thing. Forcing them to do one thing or the other is not, and will make the MoS unpopular. SlimVirgin ^(talk) 05:53, July 13, 2005 (UTC)

I've removed my personal comments about Bobblewik's motives, and I apologize for having made them. I accept that he's is acting in good faith. It's just that I find this issue a little frustrating, but that's no excuse for the ad hominem remarks. I'll also apologize to Bobblewik on his talk page. SlimVirgin ^(talk)

Tsk, tsk. No one is trying to force you to do one thing or the other. You are trying to prohibit the addition of valuable information in articles that you edit. In addition, you have repeatedly tried to cast this as a disagreement between reasonable editors and one maniacal single-issue editor, ignoring the fact the many people here have supported the addition of metric units. This is much more about your stubbornness than about Bobblewik's. Rl 09:27, 13 July 2005 (UTC)[reply]

There is inconsistency - to say that they both should be given and there is no need for them is inconsistency. And to say on a manual of style that editors can choose which style they prefer defeats the purpose of having a manual of style. Even if the principles are consistent, the text is not and should be changed. Bobblewik is not alone in his view. He is not misrepresenting the situation. People come here for a guide as to what to do. To say "do what you want" is to say "it's your choice" to someone who asks for advice.

With metric/U.S. units, I think that both should be stated, first the source then the other version in brackets, except in scientific articles and other contexts which I can't think of. In most contexts both should be there (and thus mandated as far as the MoS can mandate things), so (if people agree with me on this point) that should be explicitly stated. Neonumbers 09:56, 13 July 2005 (UTC)[reply]

Symbols for units of measurement should never be italic (as Bobblewik has done them).

The polar exploration context is another one in which miles should always be identified. This Google search dealing with Ernest Shackleton's closest approach to the South Pole shows a far too common conversion error (an error which Wikipedia used to share with many other sites) resulting from a failure to identify miles. That problem results from failure to identify the miles as nautical. Of course, since nautical miles are the conventional units in this context, if statute miles are used instead they should be specifically identified as well. Gene Nygaard 12:34, 13 July 2005 (UTC)[reply]

I prefer the existing text, as quoted by SlimVirgin. Especially number 6 - we often deal with the problem of odd source units in automobile articles. Two specific and common examples are PS and cubic inches in engine displacement. In both cases, I like to provide the more common equivalents (kW and hp for the former and cc and L for the latter) in articles. We simply must leave the original unit in the text, since it's historically significant. But since they're also unfamiliar, and since automobiles are universally enthused upon, it is courteous and helpful to provide more familiar units as conversions.

I would add one more rule: If conversions of metrics are available from a source, these shall be used rather than a more "accurate" recalculation. In many cases, a manufacturer will intentionally round up or down, or even recalculate a value for two different markets. This happens often with the kW/hp measurements. In these cases, we must use the manufacturer-provided metrics. Bobblewik pointed this out to me, and he is entirely correct. --SFoskett 13:14, July 13, 2005 (UTC)

Unchallenged changes and some of my rewording thus far make the rewrite (changes to original in non-italics, original in italics. It will not be in italics in the manual, so ignore the units being in italics here):

Wikipedia articles are intended for people anywhere in the world. Try to make articles simple to read and translate.

Metric units are permitted. This applies to all parts of all articles.
Always use the source value (e.g. from manufacurer's specifications). Write this value first, then converted units.
- Show converted value units in parentheses.
- Show the converted value units in symbolic form.
- For example '100 mm (4 in) pipe for 10 miles (16 km)'. This that the source values are 100 mm and 10 miles.
- If a source already has a converted value, use that rather than calculating the conversion yourself.
- Converted values should use a similar level of precision as the source value. For example, "the Moon is 400,000 km (250,000 miles) from Earth", not "(248,548.477 miles)".
Use standard symbols when using symbols: metre is 'm', kilogram is 'kg', inch is 'in' (not " or ″), foot is 'ft' (not ' or ′)
- Do not append an s for plurals of unit abbreviations. Thus 'kg', 'in', 'yd', 'lb' not 'kgs', 'ins', 'yds', 'lbs'.
For division (as in kilometres per hour):
- In scientific contexts, use scientific notation and with thin spaces ( ), for example kg m s^-2, g mol^-1
- In non-scientific contexts with metric units, use a forward slash, for example km/h
- With non-metric units, use the standard abbreviation, for example mph, fps
Non-metric units often have several versions. Be specific. Thus 'US gallon' or 'imperial gallon' rather than just 'gallon'. This is particularly important in nautical and aviation articles where 'mile' is ambiguous and should be 'nautical mile' or 'statute mile'.
The reader should see a space between the value and the unit symbol, for example "25 kg" not "25kg".
- But with temperatures in degrees Celsius/Fahrenheit and geographical co-ordinates, there is no space, for example "25°C" not "25 °C". Note that Kelvin does not use the degrees symbol.

I didn't change the part about Metric/U.S. units to be allowed/permitted. The part about flow of sentences (e.g. "Legend has it that the hero was a thousand miles from the volcano when it erupted." (fictional)) is implied, in my opinion, but that can be explicitly said if it needs to be. Neonumbers 02:26, 14 July 2005 (UTC)[reply]

Many sources make bad conversions, in any direction. To say that we should use bad conversions just because our sources do is sheer stupidity. What you may sometimes have is an interpretation question, in determinining which of the values given in the source is most reliable and accurate. Not everybody follows the rule of putting the original first, for example, and there are cases where the measurements can be equally valid in either measurement given, even though conversion from one to the other in either direction wouldn't give the same result (this usually happens when the value is actually known to more precision than what is stated in the article). Sometimes, where it is more of a naming question than a measurement question, or a case of making the measurements in slightly different ways in differnet units, there can be discrepancies (the AR-15 and M-16, with ammunition designated by either of the names .223 Rem or 5.56x45 mm NATO, for example, where 0.223 inch is not equivalent to 5.56 mm). But unless you can tie it to different testing conditions on different standards, and specify those conditions in some way, I don't see how that would apply to automotive engine power questions. In that case, it is probably most often an interpretation question involving the namufacturer's meaning of "horsepower", and whether that unit is 75 m·kgf/s or 550 ft·lbf/s. Gene Nygaard 14:34, 14 July 2005 (UTC)[reply]

Another naming example is floppy diskettes, where there is no need to express the conversion more precisely than 3½ inches (for example, 3.543 in), unless the actual standards for their manufacture are being discussed. The weird thing is that the manufacturers did such a good job of pulling the wool over our eyes that they even fooled their advertising people at times, with some manufacturers labeling these diskettes as "3½ in (88.9 mm)" even though they are actually designed to be 90.0 mm. This is also a good, specific example of a case in which we should not follow the manufacturer's bad conversions. Gene Nygaard 14:43, 14 July 2005 (UTC)[reply]

Does anyone know the syntax for the thin space? In my browser (IE6),   is a really wide space. Neonumbers 12:36, 14 July 2005 (UTC)[reply]

I suggest that knots are used for speed at sea, and only knots - no km/h. As far as I know no seaman use anything but knots. This is also related to the grid system used for navigation - a knot is one nautical mile, pr hour. So I propose that the use of km/h in parenthesis be dropped. Ulflarsen 13:29, 14 July 2005 (UTC)[reply]

I disagree. We are not (only) writing for seaman. Rl 14:04, 14 July 2005 (UTC)[reply]

We aren't writing just for seamen. They're a miniscule part of our audience. One important thing about SI is that it is interdisciplinary as well as international.

When I was in the U.S. Army many years ago, our maps had tick marks for latitude and longitude in grads or grades (another fairly recent name is gons). Of course, 1 centigrad(e) is to 1 kilogmeter as 1 minute of arc is to one nautical mile. Gene Nygaard 14:18, 14 July 2005 (UTC)[reply]

This discussion is hard to follow

The discussion above is getting complicated, in my view. I think it's too broad and would like to suggest it be broken down. Maurreen 06:22, 16 July 2005 (UTC)[reply]

Acceptability of both metric and customary U.S. units

My suggestion is for the style guide to include something like this: "Generally speaking, both metric and customary units are acceptable, and conversions are encouraged." Comments? Maurreen 06:22, 16 July 2005 (UTC)[reply]

Seems sensible to me, although "customary" is ambiguous. Maybe it's best left ambiguous, as it could mean US imperial, British imperial, traditional Indian units, etc. "Customary" doesn't quite seem to be the right word, though I admit I can't think of a better one, jguk 18:41, 16 July 2005 (UTC)[reply]

I left a word out. I meant to say either metric or customary U.S. units. I agree that the phrasing may be imperfect, but I can't think of anything better either. Maurreen 19:18, 16 July 2005 (UTC)[reply]

This is a style guide! It lists best or recommended style. (More a goal than a rule.) Using US/English-only measures is surely not best style (ambiguous, widely unknown), whereas it is perfectly acceptable to have metric units without any conversion given at all.

If the source/legal value is English/Imperial/US customary, fine, use it and give the metric equivalent in parenthesis. If the source value is in any other non-metric unit, use that and also give the metric equivalent, but no other. Otherwise use the metric value only.

“SI units are recommended. If using non-metric units, give conversions in parenthesis.”

I can’t stand this wishy-washy, which also applies to other areas. Christoph Päper

We really shouldn't add "US". Why should we favour US units explicitly? What's wrong with traditional British or Indian units, say? I think explicitly encouraging US units, but remaining silent on all other well-known and familiar units (depending on which part of the world you're in) is a recipe for arguments and divisiveness. Perhaps if we replace "customary" with "traditional" (and leave out any national determinants) it'd look better, jguk 19:48, 16 July 2005 (UTC)[reply]

Third attempt at a revised wording for units section

It now specifies that non-metric units are permitted. It no longer addresses editorial problems that are interesting but do not appear to cause holy wars.

Wikipedia articles are intended for people anywhere in the world. Try to make articles simple to read and translate.

Metric units are permitted. This applies to all parts of all articles.
Non-metric units are permitted. This applies to all parts of all articles.
Try to get the best source value (e.g. from manufacturer's specifications). Write the source value first and then the converted value. Use digits and unit symbols for the converted value. For example, '100 millimetre (4 in) pipe for 10 miles (16 km)'. This means that the source values are 100 millimetres and 10 miles.
Converted values should use a similar level of precision as the source value. For example, "the Moon is 400,000 km (250,000 miles) from Earth", not "(248,548.477 miles)".
Use standard symbols when using symbols: metre is 'm', kilogram is 'kg', inch is 'in' (not " or ″), foot is 'ft' (not ' or ′)
Do not append an s for plurals of unit abbreviations. Thus 'kg', 'in', 'yd', 'lb' not 'kgs', 'ins', 'yds', 'lbs'.
Non-metric units often have more than one version. Be specific. Thus 'US gallon' or 'imperial gallon' rather than just 'gallon'. Similarly, 'nautical mile' or 'statute mile' rather than just 'mile' in aviation, space, sea and some other contexts.
The reader should see a space between the value and the unit symbol, for example "25 kg" not "25kg".

Works for me. Thank you. Maurreen 13:11, 16 July 2005 (UTC)[reply]

Does anyone reading this have an idea of how hard it would be to patch the wikipedia software so that it is aware of units? The edit text could for example look like this: [[Measure:100 mm]], and be presented like "100 mm (4 in)" or "100 mm" or "4 in" etc, depending the user's preferences. Just an idea, anyway; I don't have time to look into it myself at the moment. Grahn 19:08, 16 July 2005 (UTC)[reply]

Numbers written as words

I can't find any guideline on how (or whether) to hyphenate numbers when written out as words, such as forty-two. My instinct is to hyphenate it, but I have seen it not hyphenated on WP so I don't know if this is a US/UK difference. If it is to be hyphenated, what should I use? The hyphen-minus, or a unicode character? It seems odd that Hyphen#Hyphens_in_computing says "Usage of the hyphen-minus character is discouraged where possible, in favour of the specific hyphen character" yet this MoS says to use it. — PhilHibbs | talk

I am not aware of specific guidance on numbers written out as words. However, there are guidelines that encompass the issue. My summary is: A hyphen is an optional tool to be used when it fulfils a purpose. If that purpose does not exist, then do not use a hyphen. For example, an author can use a hyphen for the purpose of linking number word pairs when the reader might reasonably have more than one choice of interpretation of the text.

For example:

'forty two sheep' (only one reasonable interpretation -> no hyphen)
'forty-two millimetre thick wires'
'forty two-millimetre thick wires'

I quote the references on my style talk page in the Hyphens section. Bobblewik (talk) 12:25, 13 July 2005 (UTC)[reply]

Numbers twenty-one through ninety-nine are always hyphenated. And it's "forty-two-millimetre-thick wires," but 42 mm thick wires (abbreviations always open). —Wayward 12:44, July 13, 2005 (UTC)

So would anybody object to this being written into the MoS, or should it be left out as it does seem to be a standard rule of written English, rather than a matter of personal or national preference? (p.s. the Times's Style Guide is an interesting read, but I'm surprised that they don't clarify the posessive form of Jesus.) — PhilHibbs | talk

I don't see any point in being prescriptive here. Incidentally, most prescriptive style guides say something completely different: namely to write out the numbers one to ten, but to write higher numbers in digits. So, for example, if you have five sheep and then get six more you have 11 sheep. If you then get nine more you get 20 sheep, but I don't see a need to prescribe this rule either, jguk 18:57, 13 July 2005 (UTC)[reply]

Yeah I was taught one through ten and 11–20. I'm sure in some articles it's useful to write numbers as numbers, too. I rarely see twenty-four written out. - Omegatron 19:48, July 13, 2005 (UTC)

About figures or words, the Chicago Manual of Style states the following:

"According to Press style, the following are spelled out in ordinary text:

Whole numbers from one through ninety-nine
Any of these followed by hundred, thousand, million, etc."

The exceptions are scientific writing (45 pounds, 3 cubic feet)—which would apply in our scientific articles—and clusters of numbers (e.g., their ages were 69, 64, 54, 47 and 35). They note that newspaper style, as well as that of some general publishers and scholarly journals, decrees that only the numbers from one through nine and such multiples as one hundred or nine thousand are to be spelled out. Sunray 20:19, July 13, 2005 (UTC)

The problem with the Chicago Manual of Style is that whilst it has quite a lot of respect in America, it has very little respect elsewhere in the English-speaking world. Returning to the point in hand, though, it is clear that it is not appropriate to enforce any one particular style, jguk 20:38, 13 July 2005 (UTC)[reply]

Since you have no respect for Chicago, perhaps you respect Oxford?

Oxford Style Manual (2003), 7.1.2: "In non-technical contexts, OUP style is to use words for numbers below 100. "

Oxford Style Manual (2003), 5.10.5: "Use hyphens in spelt-out numbers from twenty-one to ninety-nine (twenty-three, thirty-fourth, four hundred and sixty-eight, fifty-three thousand), and in fractions, unless the numerator and the denominator are already hyphenated (one-half, two-thirds, three thirty-seconds, four and five-eights)."

I'd say hyphenating numbers 21–99 is near universal. Can you cite a guide that recommends not hyphenating them?

—Wayward 02:44, July 14, 2005 (UTC)

Not a rule, just a comment that specific proper names such as Twentynine Palms, California are based on early 20th century U.S. Post Office rules. Gene Nygaard 13:23, 14 July 2005 (UTC)[reply]

With the OUP "non-technical contexts" rule, we should also include a technical contexts rule, such as this one from NIST: [12]

"This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible. This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using

"the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and
"the symbols for the units, not the spelled-out names of the units."

I'd also say that much of the reasoning ("as independent of language as possible") would apply even in more general, less technical contexts here on Wikipedia, especially the English Wikipedia. Gene Nygaard 13:23, 14 July 2005 (UTC)[reply]

But if people come here for a guide because they don't know what to do otherwise, the least we could do is have some advice for them.

There'll be some places where it's better to use words, and we should have a guide for those places, even if they are few. I say numbers from 20 to 99, when written out in words, are hyphenated. (I normally put eleven to twenty in words and 21-99 in numbers, but I think I'm the odd one out)

Which style we choose here isn't that important, but the manual of style exists to guide editors stuck over style issues, and it should live up to its job, so something about this should be on the manual. Neonumbers 01:47, 14 July 2005 (UTC)[reply]

Taken together, Oxford and Chicago style manuals are considered absolutely authoritative. I move we standardize on the above and spell it out for our users in the Wikipedia Manual of Style. Sunray 05:34, July 14, 2005 (UTC)

We should not over-specify the English language. There will be an obvious exception to this rule, but literal-minded editors will point to the guideline as gospel and start revert wars over it. —Michael Z. 2005-07-14 06:30 Z

MoS is not enforced, it's guideline only. I would be astonished to see a revert war over a subject like this. — PhilHibbs | talk 12:01, 15 July 2005 (UTC)[reply]

It will definitely happen. - Omegatron 15:22, July 15, 2005 (UTC)

I appreciate Sunray will be unfamiliar with British usage, so I should point out that he is quite mistaken to say that Oxford and Chicago style manuals are considered absolutely authoritative. The Oxford style manual does not represent the most common form of the language used in Britain (let alone the rest of the English-speaking world). For instance, very few British publications other than those produced by the OUP use -ize rather than -ise (similarly for writers). The mandatory Oxford comma is rare outside OUP's publications - and these are just two examples of Oxford house style which you will not see common usage outside the OUP, jguk 19:14, 14 July 2005 (UTC)[reply]

Style guides often do not reflect the most common usage—it is not their purpose. Style guides present a set of commonly acknowledged practices that are accepted in their respective academic fields. —Wayward 03:06, July 15, 2005 (UTC)

I've never seen any respectable source that doesn't hyphenate numbers; I can't see any mention of one above (but there's a lot there, and I might have missed it). --Mel Etitis (Μελ Ετητης) 22:58, 14 July 2005 (UTC)[reply]

General British usage (unfamiliar with which as I may be) is surely not our main concern in an encyclopedia. We tend to follow academic standards and style for our articles (albeit written as readably as possibly), rather than newspaper or magazine style guides. Perhaps Jguk could refer us to an appropriate style guide for academic British usage if the Oxford Style Manual is insufficient as a resource. For North American usage, the Chicago Manual of Style is considered authoritative, as the Wikipedia Manual of Style makes clear here. Sunray 02:37, July 15, 2005 (UTC)

Ditto above. Neonumbers 12:58, 15 July 2005 (UTC)[reply]

I agree. This isn't a magazine. - Omegatron 15:22, July 15, 2005 (UTC)

True, but we aren't an academic text either and certainly shouldn't be using an academic style guide. IMO we should imagine our readers have the knowledge and reading skills of a reader of a broadsheet newspaper. I don't mean we should copy newspaper style (as generally we shouldn't), but in choice of words and language style, we shouldn't be too different. I don't think there's one single British English style guide that can be considered wholly authoritative. As a useful guide though, if you stick to what The Times has, you won't go far wrong, jguk 06:22, 16 July 2005 (UTC)[reply]

I strongly disagree with basing the Wiki MOS on any newspaper house style. Newspapers cram much more text into each square inch than do other publications, and therefore they are extremely concerned with saving space (space + ads = $). A few examples from The Times style guide: No degree symbol in temperatures, 15C (-2F); no spaces with other symbols/abbreviations, 5ft 7in (1.7m), 1,343m (4,406ft); no space with AD/BC, 350BC; no space or points in times, 6pm; no points with Latin abbreviations, ie, eg, etc; days abbreviated, Mon, Tues, etc.

Getting back to the original posters question about hyphens in spelt out numbers, The Times guide uses a hyphen in "twenty-three" here under "hour and a half, an." —Wayward 09:46, July 17, 2005 (UTC)

I wasn't intending to suggest we adopt The Times style guide wholesale, merely that it's a reasonably fair indication of the most common usage in modern British English - though there are a few exceptions. In the examples you give, if I was writing I'd probably put a degree symbol in temperatures, have no space in 5ft 7in (though I'd probably write it 5'7''), have a space between AD and BC and the year, write 6pm and omit points after abbreviations (ie, eg, etc). I think the only real difference you'd see with others is that some do continue to put points in abbreviations.

As a general point, the tendency in the UK has over the last 60 or so years been to reduce the amount of punctuation used. This tendency has also been adopted throughout the English-speaking world, except in North America. Ironically, if you look at a nineteenth century British English text, you'll see it punctuated in the same way as a twenty-first century American English text is punctuated! The difference between twenty-first century British English punctuation and American English punctuation can be very marked indeed, jguk 10:23, 17 July 2005 (UTC)[reply]

This has been an interesting discussion and I think we have consensus (though not unanimity) on a number of points. There is obviously a lack of clear guidelines on numbers as words in the Wikipedia Manual of Style. The commentary here seems to suggest that we should have guidelines to assist editors who have questions. Most who have commented agree that:

Double numbers from one to ninety-nine should be hyphenated.
Numbers from one to ninety-nine should generally be written.
An exception to this is scientific writing, in which Arabic numerals should be used.

Have I got that right? If so, do you agree that we should add a few sentences to the MoS along these lines? I assume we all take the point that the MoS is a guideline, not a law. Sunray 16:02, July 17, 2005 (UTC)

Er, no. I very, very strongly disagree that the MOS should recommend spelling out numbers from 1-99. And I don't see much of a consensus on that point above. I'd be OK with always spelling out 1-10, but above that it should depend on the context and the preferences of the editor. I've no problem with the hyphenation rule. older≠wiser 16:24, July 17, 2005 (UTC)

Here's my tally:

Hyphenization: For: Wayword, PhilHibbs, MelEtitis, Sunray. Against: None. Optional: Bobblewik.
Written words in text: For: Wayward, Omegitron, Sunray. Against: Jguk, Bknorad. Either: Neonumbers.
Numbers in scientific contexts: For: Gene Nygaard, Sunray. Against: Nil

Consensus on talk pages is usually a two thirds majority. So we have consensus on hyphenization, but with Bkonrad's nay we do not have consensus on writing out words in text. Sunray 19:32, July 17, 2005 (UTC)

That tally does not represent my position. My position is:

Hyphenization: Against. Bobblewik. As I said above, the hyphen is only a tool to resolve ambiguity. Otherwise it adds no value. If there is only one reasonable interpretation there is no benefit to a hyphen. See the quotes from styleguides on my page.
Written words in text: Against. Bobblewik. Digits yes please, they are easy to read and translate. Words no thank you.
Numbers in scientific contexts: For. Bobblewik. Digits yes please, in all contexts.

I am quite comfortable with the situation as it is. The Manual of Style should only contain advice where there is: (a) confusion that causes a problem or (b) conflict that causes a problem. I don't see either in this case, we merely had one question.

Bobblewik (talk) 20:23, 17 July 2005 (UTC)[reply]

I'm not sure we need to add anything about hyphenation. Isn't that at least close to being universal? Also, I prefer to use numerals for numbers of 10 or more. Maybe we should just leave it to the users' choice. Maurreen 19:56, 17 July 2005 (UTC)[reply]

None of the style guides you cite on your page say to leave out the hyphens in numbers not divisible by ten from twenty-one to ninety-nine, Bobblewik. Gene Nygaard 21:02, 17 July 2005 (UTC)[reply]

The quotes from styleguides describe the use of the hyphen as a tool to resolve ambiguity. The phrase forty two sheep has no reasonable ambiguity so a hyphen adds no value. Some people like to use hyphens in such cases. That is their choice but I don't want to be told to do it. According to Fowler: If you take the hyphen seriously, you will surely go mad. Bobblewik (talk) 21:41, 17 July 2005 (UTC)[reply]

Abbreviations for timings

A problem has cropped up regarding how timings (for albums, tracks, and singles) should be expressed. At the moment there are various styles, the main three being:

45 min 34 sec
45:34
45' 34"

The first is used in the Template:Album infobox; all three are used by various editors in various articles.

The official SI abbreviations are "min" and "s" and they are never written with fullstop or plural s (see also ISO 31-0).

The first seems to me to be odd: the Wikilinking is surely unnecessary, the abbreviations (lacking either plural or full stops) are incorrect, and I've rarely if ever seen it used elsewhere.

The second is often used on album covers, etc., but it's the same form as used in Wikipedia for times of day, and thus could conceivably cause confusion.

The last is pretty standard, being used not only on many album covers, etc., but in other contexts too.

OK, my preference is pretty clear — but I'd rather that one of them were chosen as the recommended style even if it weren't my preference than that we continue with the free-for-all that we have now. I was certain that I'd seen something on this in the MoS, but I can't find it; is there anything? If there isn't, shouldn't there be? --Mel Etitis (Μελ Ετητης) 18:25, 17 July 2005 (UTC)[reply]

The modern rules for abbreviations for units of measure are never change them in plural, and never use fullstops. The modern symbol for seconds, of course, is "s" rather than "sec".

The second form, used on album covers, is reasonable. There is no real difference between this and times of day (it's like the difference between a temperature reading and a temperature interval, which can both be expressed by using °F, etc.), and little likelihood of confusion in any case. I say use that one.

That prime and double prime format is common for minutes and seconds of arc (as fractions of a degree, but not of an hour), uncommon and unusual for minutes and seconds of time, and IIRC improper according to some style guides. For time (and also for hour angles), you are much more likely to see formats such as 3^h 18^m 25^s. Gene Nygaard 19:27, 17 July 2005 (UTC)[reply]

See the discussion of abbreviations for timings that took place last year in WikiProject Albums. Bobblewik (talk) 20:32, 17 July 2005 (UTC)[reply]

Thanks for the link. The trouble for me is (as with Gene Nygaard's message above) the discussion is full of people claiming that certain forms are unfamiliar and confusing when they're in very common use. The main one here is: (mm' ss"). Just plucking CDs from my shelf at random, they're almost equally divided between those using mm:ss, those using mm' ss", and those offering nothing (none use the peculiar "mm min ss sec" — and even without the unnecessary links, that still looks odd to me). With regard to G.N.'s claim, by the way, where do we find "the modern rules for abbreviations"?

In my opinion, the examples at the top of this section are listed in descending order of clarity. Of course, there's nothing wrong with adding periods or spelling out the words either. Maurreen 22:22, 17 July 2005 (UTC)[reply]

See also

Non-base ten numbers

Unit Disagreement, MiB vs. MB

Vote

The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts

The MoS should encourage the use of the IEC prefixes only in highly technical contexts

The MoS should discourage the use of IEC prefixes anywhere

The MoS should not mention this issue at all

No more stupid votes

The Wikipedia should only represent common usage

Permitting removal of metric units: inconsistency in the Manual of Style

Possible principles for units and systems of measurement

Suggested rewrite of 'units' section in Manual of Style

This discussion is hard to follow

Acceptability of both metric and customary U.S. units

Third attempt at a revised wording for units section

Numbers written as words

Abbreviations for timings