Wikipedia talk:Manual of Style/Dates and numbers/Archive 39

Archive 35

←

Archive 37

Archive 38

Archive 39

Archive 40

Archive 41

→

Archive 45

"US Date" Comma Issues

When preferences are set to use customary US dates (ex: February 10, 2006), in many cases, the date is not rendered properly within prose. For example, by wikilinking a date and having preferences set to show up in US format, somethign will show up as

This happened on February 10, 2006 because of that.

however, this is incorrect usage; it should be

This happened on February 10, 2006, because of that.

The year (2006) in this date format is parenthetical and must be set off by commas on both sides. However, this is not true in at least two cases:

• If the date's an adjective: The September 11, 2001 attacks on the WTC...
• If the date's alone somewhere. Meaning like... birth and death dates.

Originally, I had my preferences set to 2006-02-10 format, so this was not an issue. But when I figured out that this did not simply apply to signatures or watchlist/history dates and also (well, it does not modify signatures, but it does do this:) changes article dates that have been linked/formatted to do so, i changed to US format (Feb. 10, 2006). I noticed the comma errors, and not realizing that it was automatically done really, I ended up adding a lot of commas into articles after dates. But now I realize that this is not a solution, as the above becomes

This happened on 2006-02-10, because of that.

(I'm not happy with this example because some people would argue that there should be a comma there because of because, but for the sake of not having to think of a better example, let's pretend that there should NOT be a comma there due to because (even if there should be one).)

Therefore, I recognize that it would be impossible to correct the problem by adding in a comma to the software that converts the dates based on preferences. However, something has to be done, because the pages are being rendered grammatically incorrect with this date preference. I don't think anyone here has the ability to do so, but I think the best way to do this (aka change the software's settings for converting dates) would be to encode date years like [[2006]] for when there should NOT be a comma and [[2006,]]<nowiki> for when there SHOULD be a comma when rendered Feb. 10, 2006. However, this then means everyone, even those who do not use US date format, would have to think about if a comma is needed in US date format or not. So this, obviously, might not work. However, something must be done. When 2/3 of first-language English speakers speak American English and most likely use US date format, it's not acceptable for most dates to potentially be rendered grammatically incorrectly... which will have the adverse affect of making peoople think that NO COMMA is the '''correct''' format and will cause them to do make more grammar mistakes than they already do when writing their own prose (not just on WP, but everywhere). Thanks for your attention on this matter. I apologize for the typos; I'd rather not waste my time perfecting prose on a talk page. ~~~~

This is a grammar issue, not a coding one. I would suggest that the comma is required in that phrase regardless of the date format. Rmhermen 16:46, 20 February 2006 (UTC)

Let's take a better example: "A ceremony was held on 11 September 2002 to mark the anniversary of the attacks on the World Trade Center". I wouldn't put a comma in this sentence. What would Americans write? Stephen Turner (Talk) 17:02, 20 February 2006 (UTC)

"A ceremony was held on September 11, 2002, to mark the anniversary...." The commas before and after the 2002 are BOTH required. But if this is written as

... on [[September 11]], [[2002]], to mark...

then it will appear grammatically correct when someone has the date format set to "Month #, Year" (US Style), but if your date preferences are unset, set to something else, or not able to be set (unregistered user), if you have a different format than US format, it will show up as

... on 11 September 2002, to mark...

, which is not grammatically correct becuase in DayMonthYear format, no commas are used (becuase unlike in US format, the 2006 is no longer parenthetical).

This is the above code (in the box) written into the text and allowed to be wikiconverted:

... on September 11, 2002, to mark...

Therefore, this is a coding problem, not a grammar problem, because in many (not all) cases, regardless of what you do, the end result will wrong for at least one if not more "date formats" because of the way the software replaces the dates. (and as I said above, although the use of because does not require a comma (ex: He did that because of that. NO comma. This happened [on date] becuase of that. NO comma unless you use US date format, then one is required. However, I specifically stated above that becuase some people will argue that there should be a comma there because of because, that for the purpose of the example it should be conceded that there not be a comma there)).

There probably is not "easy" solution to this, but I think it's a shame that a project that wants to become an authorative encyclopedia has such a giant flaw like this. I do not really get the purpose behind the date format thing, either... I mean, the encyclopedia doesn't seem to care that on half the pages it says "color" while the other half say "colour," so it does not make much sense why it tries to change dates over inside prose, which does not work well. I am rather suprised, too, becuase at first, I thought the date preferences were for things like signatures or watchlists or contributions pages--stuff the "encyclopedia user" would not see, but stuff that would allow users to easily convert UTC dates and times into their own formats. Instead, though, it appears to be the opposite, and instead, it tries to change over pages themselves.

Again, most people don't seem to care about grammar, but if something's an encyclopedia... well, it sort of has no choice if it does not want to look like a joke compared to other sources of information. //MrD9 04:46, 21 February 2006 (UTC)

I think there is a simple developer fix to add a comma after American style dates if there isn't one already. This will only leave the problem when people put a comma explicitly after the date solely to set off the year, which would be a difficult user education problem, and a difficult development problem. Rich Farmbrough. 12:05, 23 February 2006 (UTC)

It's not that simple, though, because there are both cases when there should and should not be a comma. For example, if you're simply writing the (I'm making this example up) "Date state entered the Union:" value in a table or template, you want it to say "January 3, 1800" and not "January 3, 1800," (which an automatic, software-inserted comma would do.) Furthermore, for example, dates used as adjectives do not get comma's after them: "The September 11, 2001 attacks on the World Trade Center..." (no comma)

Basically, I can think of no solution other than to not have dates auto-converted... instead, in a table or list format, ISO could be used (2001-09-11), US-related articles Sept. 11, and UK articles 11 Sept., but this obviously is not possible (and then for non-country-specific articles, aka most of them, what do you do? just pick one format and stick with it?)

Although I'd hate to admit it, there does not seem to be a good solution other than what I said, but I doubt it'd be implemented, or if implemented, used correctly...

[[September 11]], [[2001]] --> September 11, 2001
[[September 11]], [[2001,]] --> September 11, 2001,  [or]  11 September 2001  [or]  2001-09-11  [or] whatever else...
Basically, "," inside brackets = use comma when user has setting to US Date Format, otherwise just do date
no "," (regular date) = print as normal (aka date used as adjective or not in a sentence, so no comma regardless of date format)

//MrD9 22:33, 23 February 2006 (UTC)

I agree, I can't imagine it would be used correctly by American users, let alone by users from other parts of the world. Stephen Turner (Talk) 22:44, 23 February 2006 (UTC)

Prefixes - headers

I've changed these as they had beoe a bit confused (or at least I had) . Any ptroblems, please fix or talk to me, as usual. Rich Farmbrough. 11:51, 23 February 2006 (UTC)

Date formats related to topics

Once upon a time this was a bit clearer, but now it's lost under the subheading Dates in article titles which seems to only relate to the first sentence, and that could easily come under the previous subheading Usage of links for date preferences. I therefore propose that the subheading be changed to Date formats related to topics and put after "In article titles, dates will not be converted" which will form the last sentence of the previous subsection. so that the subsection begins with "It is usually preferable to use the format preferred in the variety of English that is closest to the topic". This would help to avoid the perennial problem of date formats being changed inappropriately. ....dave souza, talk 19:10, 27 February 2006 (UTC)

Done. The section has been significantly weakened since 27 February, and this change in guidance needs to be carefully considered. ...dave souza, talk 09:06, 7 March 2006 (UTC)

spaces before unit symbols

User:JP06035 added an exception to the general guidance about spaces: Due to the consensus of a recent Wikipedia forum, all metric numbers written in Olympic articles (like olympic medal counts, results pages, games pages, etc.) shall be written like this: 1500m , 20km , 4 x 10km , etc.
Sources: Discussion Results ● Archived Discussion'

I reverted the text but perhaps we can regard it as a User:JP06035 initiated proposal for a change. What do people think? bobblewik 13:03, 8 March 2006 (UTC)

Well it's not a proposal; it was decided by the Olympic conventions forum, and had a pretty good consensus, too. Its what most of the olympic related websites use even the IOC, which is the most trusted source for Olympic related things...it's usually the last resort for the forum. (see this page for an example of the IOC's use). I know this is what the people want, so I advise you to switch it back. --Jared ^[T]/_[+] 13:22, 8 March 2006 (UTC)

Nothing was decided there:

• There was no consensus on anything.
• That is a bogus page, not part of Wikipedia:WikiProject Sports Olympics. Jared claims ownership of it, too.
• Whatever straw polls there were were not publicized on WikiProject Sports Olympics, here on MoS (dates and numbers), nor anywhere else.
• Even if Jared's claims were true, it would be in conflict with the guidance here on the MoS, as well as with the rules of the standards-keepers.

Unlike the ludicrous claims on Jared's user page that "I created this series of debates which will now stand as current Wikipedia policy", his page has not even created any guidelines, let alone policy.

Gene Nygaard 13:43, 8 March 2006 (UTC)

I support User:JP06035's interest in units but I happen to think he/she is wrong in process and in decision. Process: the MoS is the best place to question MoS guidance and it is unreasonable to expect us to accept any change to MoS guidance without discussion. Decision: the nine people with an Olympic focus may have acted in good faith but people here have Wikipedia-wide focus that those nine did not discuss. An exception could never be contained just to Olympic articles, it must affect all sports articles. It will also affect any article that mentions a sport. Editors will have two different formats and complicated cross-over rules that will never be properly implemented. bobblewik 14:16, 8 March 2006 (UTC)

Update: I have nominated Wikipedia:Olympic_conventions for deletion. See Wikipedia:Miscellany for deletion/Wikipedia:Olympic conventions. Gene Nygaard 15:48, 8 March 2006 (UTC)

The MoS has worked very well for a long time. I happen to agree with bobblewik on this one. One of the things that make Wikipedia work well is consensus. In my profession (chemist), we write measurements with the number space symbol (except temperature [e.g. 77°F], but that is more a company mandate than anything else). The MoS for the most part is inline with some of the scientific writing manuals that we have on the shelf in our library. You can find some if you search the internet. Those are my thoughts, what's your? MJCdetroit 17:01, 8 March 2006 (UTC)

I personally don't have an opinion whether it should be 1500 m or 1500m. However, as I said in my vote on the conventions page, since the Manual of Style says it should be 1500 m, we should follow that. I don't think that a 9/6/0/1 vote is a "consensus". It's barely a majority of the votes at 52%. While there are some things on the conventions page that have been helpful to discuss, a decision to go against the Manual of Style should be overwhelming. This one is obviously not. Sue Anne 17:11, 8 March 2006 (UTC)

I believe that thew MoS should be the last resort, but who doesn't agree with me that the IOC should come first? I mean come on, its olympic articles, not articles about a car or a floppy disk, but Olymppics. We don't refer to un-Olympic sources for Olympic things...that should be the way it is! --Jared ^[T]/_[+] 20:43, 8 March 2006 (UTC)

It is also only 9/6/0/1 because Jared improperly closed the vote after a few days of discussion on an unpublicized corner of Wikipedia space. My vote isn't counted, which would be added to the 6 on the second one. I don't think it is any stretch of the imagination to guess that Bobblewik would also support that. Or Crissov, who has recently edited the other ambiguous related vote on Jared's little private domain. Gene Nygaard 21:20, 8 March 2006 (UTC)

One difference is that the IOC does not declare this as a rule to be followed. Or can prove me wrong, Jared? OTOH, NIST (see [1]) and National Physical Laboratory, UK (see [2]) and Wikipedia:Manual of Style (dates and numbers) do state the use of the space as a rule to be followed. Gene Nygaard 21:29, 8 March 2006 (UTC)

Gene, apparently you don't see my logic here...if no one is leading or heading something...there'll be chaos. I had it posted for a while now that it would be closed in a week or so, in the case of this debate, I kept it open for alteast 2 weeks because there werten't enough votes for either of the sides (and actually my side was winning, FYI). I don't just think of myself. Further, I can't leave a debate open forever. What if I went on vaca and a page of mine was nominated for deletion? 7 days later it may be deleted, and I never once got to it. You think you can just get me on this because you think I may be vulnerable, but in fact you can't and it's your fault for not finding the page fast enough to show your opinion. --Jared ^[T]/_[+] 21:31, 8 March 2006 (UTC)

When you didn't have consensus, you could have just said so—without falsely claiming that you did. Gene Nygaard 21:38, 8 March 2006 (UTC)

There was a consensus....most people found that the current was (1500m) was correct. Case closed. --Jared ^[T]/_[+] 21:42, 8 March 2006 (UTC)

Hey, here's something for you to do...go to Google.com and type in 1500 m. It will say "Did you mean 1500m. Then do a search for 1500m. Which had most of the olympic articles on it? I thought so. It's the preffered way!--Jared ^[T]/_[+] 21:36, 8 March 2006 (UTC)

Results 1 - 10 of about 4,640,000 for "1500 m". (0.05 seconds)

Results 1 - 10 of about 4,520,000 for "1500m". (0.04 seconds)

Well, on a strict majority rule, your example fails. It's kind of a George W. Bush majority though. My vote, as always, goes for correct and universally accepted (in all disciplines) style, over jargon.—Daelin @ 2006–03–18 09:34Z

Proposing a major change to binary unit prefixes policy

Specifically, I object to this part: "If a contributor changes an article's usage from kilo- etc. to kibi- etc. where the units are in fact binary, that change should be accepted." It is my very strong opinion that the IEC prefixes are jargon that should be avoided, and that the prefixes that are in common usage should be the ones that are favoured. I have argued this on another article's talk page, and rather than rephrase those arguments, I will paste them below: thus, the contents of the following two paragraphs are the arguments I made in Talk:Intel Core. Jgp 00:53, 10 March 2006 (UTC)

You're arguing to existing common usage. Standards bodies have come up with good solution to the various problems of the mis-use of the decimal multipliers. The binary multipliers may not currently be as prevalent as the old broken system. But if we are ever to get to using the standards-based system, it's not going happen in a "big bang" style; it's going to be a gradual change. There are going to have to be points along the line where both systems are in use. The longest journey begins with a single step. It could start with those people who are enlightened enough to see that it should be changed, and who have the opportunity to make the change. Wikipedia is a good place to do this because the new units can be easily explained by means of wikilinks. Duckbill 18:13, 10 March 2006 (UTC)

That sounds like advocacy to me, which is what Wikipedia is not. Wikipedia should not be used to push one system of units over another in order to advocate a point of view. Also, a "standard" that was made up and isn't in common usage really isn't standard. Just because an important group made it up doesn't mean it should be used. Using (and especially advocating) a term that isn't in common usage over a term that is in common usage just because a small group of people made it up out of thin air is intellectually dishonest. If KiB/MiB/GiB becomes common usage, I'll relent, but it's extremely uncommon, and using Wikipedia as a platform to advocate it is wrong. Wikipedia is not the place to advocate such change. It goes against both the "what Wikipedia is not" policy and the NPOV policy. The purpose of Wikipedia is to collect knowledge about and describe the state of the world in the past and present, not the state of the world as you believe it should become in the future. Jgp 20:28, 10 March 2006 (UTC)

Let's see--how many years were computers in common use before the IEC pulled those units out of thin air? They were introduced in 1999, at the tail end of the first dot-com boom, long after computers and basic terminology such as "Megabytes" and "Gigabytes" became commonly used by the general public. I talk to many people, both computer-literate and not, and none of them use that -bi- garbage. When I help people with their computers (including people who aren't computer-literate), I ask them how much RAM they have, and they reply with something along the lines of "It says I have 512 Megabytes", "I've got a gig", etc. I open up a newspaper and look at the ads: when memory is mentioned, units such as "MB" and "GB" are used. I bring up the website of any major electronics store (including stores that cater to common people and not to geeks), and they all refer to memory in MB, GB, etc. The binary unit prefixes are the very definition of jargon: it's something that's never used when communicating to the general public (and when the general public must be communicated to, alternative, more commonly-used terms are used instead), it's completely unknown except to computer geeks and professionals, and only a very small subset of those geeks and professionals actually use them. Jgp 00:53, 10 March 2006 (UTC)

The older terms, on the other hand, are in common use by everyone except a small group of geeks and pedants. Furthermore, the common person knows that words can have different meanings in different contexts. Here's an example: "I was just looking at my hand". Normally, this means that I was gazing at the appendage at the end of my arm. But if I'm playing cards, it means that I'm looking at the cards I was dealt. The same word, or even the same phrase, can mean something entirely different depending on the situation, and any intelligent adult can understand that. Jgp 00:53, 10 March 2006 (UTC)

Also, I've got a question: is there anywhere else I need to go in order to make this an official proposal? Or is proposing it on the talk page all I need to do? Jgp 00:53, 10 March 2006 (UTC)

I'm not a computer expert, so I'll ask: is this in terms of accuracy of description? i.e. is MiB more accurate than MB? If so, I would say that including both in technical descriptions could be appropriate (with MiB in brackets, as it is in Intel Core now). But if there is little difference between the two, then using the much more common MB / GB designations seems like common sense. Ziggurat 01:04, 10 March 2006 (UTC)

Yes, MB is ambiguous and can mean either 1,000,000 bytes or 1,048,576 bytes. MiB always means 1,048,576 bytes, and most standards organizations recommend that MB be used in its decimal meaning only; 1,000,000, like mega- means everywhere else. We've had this discussion a million times before, which is why the policy was created in the first place. Here's the original policy discussion: Unit Disagreement, MiB vs. MB — Omegatron 01:26, 10 March 2006 (UTC)

Except for the fact the IEC units are only used by a small subset of computer experts. Neither laypeople nor the majority of computer experts use them (and almost the entirety of the former group has no idea they exist), and thus they are unnecessary jargon. Furthermore, the IEC prefixes were only made up relatively recently compared to how long computers were in public use before that. There's nothing wrong with words that can mean different things depending on context--common people do it all the time and have no problems with it (see my "hand" example above--even an entire sentence using "hand" can mean completely different things depending on context). Common usage should always trump pedantry. Jgp 01:41, 10 March 2006 (UTC)

Laypeople don't know that KB = 1024 bytes, either. Only a small subset of computer experts users.

The computer misuses of SI prefixes were only made up relatively recently (40 years or so?) compared to kilo- meaning 1000 for the last several centuries.

We've been through this a (decimal) million times before, as linked above, and almost everyone agrees with the current wording. Wikipedia is an encyclopedia; not a comp sci textbook, and has to represent numbers in a way that is unambiguous across all fields. — Omegatron 02:10, 10 March 2006 (UTC)

Laypeople use KB. Laypeople have never heard of KiB. All computer experts know that KB = 1024 bytes in certain contexts, and most of them use KB over KiB. I'd even argue that there are more laypeople who know that KB refers to more than 1000 bytes than laypeople who have heard of KiB. Jgp 02:16, 10 March 2006 (UTC)

All computer experts know that KB = 1024 bytes in certain contexts

What was that you said about unnecessary jargon? — Omegatron 02:19, 10 March 2006 (UTC)

That was a reply to your needlessly sarcastic comment about how only a small subset of computer experts knows that KB = 1024 bytes. Furthermore, that was not the only piece of evidence I used as to way binary unit prefixes are a Very Bad Thing (did you not see "Laypeople use KB. Laypeople have never heard of KiB."?). Don't put words in my mouth. Jgp 02:26, 10 March 2006 (UTC)

Needlessly sarcastic?

Binary unit prefixes are a Very Good Thing.

Anyway, we've been through this enough times. Go read the policy discussion. — Omegatron 03:19, 10 March 2006 (UTC)

The much older SI prefixes were formally adopted in 1960, computer misuse of the prefixes became popular about twenty years later. Would it not be an improvement to keep KB, MB, GB and TB with each incorrect use incorporating a piped link to the IEC equivalent? The muddle needs to be cleared up, as anyone who noted the court case about hard drives measured in GB not accommodating the same number of GiB will recall. ...dave souza, talk 09:50, 10 March 2006 (UTC)

All computer experts know that for instance ‘MB’ is often used in the binary sense. Almost nobody knows when this is definitely the case! (See for example CD vs. DVD.) Joe Sixpack, i.e. the average Wikipedia reader, OTOH does not know nor expect that ‘MB’ could mean two different things, and standardisation bodies actually are on his side. Joe Sixpack will usually ignore the additional letter ‘i’ in ‘MiB’, but it is a disambiguation hint for the computer expert. I therefore see no reason not to prescribe binary prefixes where applicable. Christoph Päper 11:29, 10 March 2006 (UTC)

If MiB is linked, it is harmless. If it is not linked, it will be routinely "ocrredted" as an obvious misprint. Bo change of policy is needed. Septentrionalis 16:14, 10 March 2006 (UTC)

Not necessarily. If the page is watched, the misguided correction will be reverted, and the person making the misguided correction will learn something. Alternatively, a comment can be placed in the wiki markup to point out that the term used is in fact correct. Duckbill 18:05, 10 March 2006 (UTC)

Whether MB means 1,000,000 bytes or 1024^2 bytes doesn't affect Joe Sixpack. Only a computer expert would actually be affected by such a detail. The fact remains that KB/MB/GB are the terms that are in common usage and thus they are the terms that should be used. As I've said before, get a newspaper and look at the ads for Best Buy, Circuit City, CompUSA, or any electronics store that caters to Joe Sixpack. If your newspaper doesn't have such ads, look at the websites of the aforementioned companies. You'll never find Joe Sixpack complaining about how the units are confusing. Joe Sixpack will happily tell people that the sticker on their (OEM-built) computer says that their computer has 512 MB of RAM, and they won't be confused by the usage of "MB". Jgp 16:37, 10 March 2006 (UTC)

Yes but that sticker is WRONG! In that context it doesn't matter that the sticker is wrong because (a) it's just giving a feel to the customer of the rough amount of memory in the machine, and (b) the retailer is not legally exposed because the machine does in fact have 512,000,000 bytes (512 MB) of memory — it also happens to have another 24,870,912 bytes of memory as well. But Wikipedia isn't a sticker on a computer in a computer shop. Wikipedia is an encyclopedia. It should contain information that is accurate and verifiable. In the example you mention here, 512 MB is off by some 4.6%. 512 MiB is exactly correct, and uses entirely standard units. Standards don't get laid down until a lot of well-informed people are happy with them. Standards bodies know that a lot of people are going to base their work on things that they say and take a lot of care to get them right. Duckbill 18:25, 10 March 2006 (UTC)

It's not wrong. The same word can have different meanings in different contexts. Jgp 20:28, 10 March 2006 (UTC)

The current guideline is fine, allowing casual use but recommending precise units where they matter. This is an encyclopedia, and there's no need to baby the reader if the text is written well enough. Maybe someone reading it can learn something. —Michael Z. 2006-03-10 17:30 Z

Actually, while out shopping I just came across the classic case where it does matter to Joe Sixpack: browsing CompuerActive magazine, it gives guidance in simple language for beginners that a 4.7 GB DVD only takes what your computer calls 4.3 GB, a good way to fail to record data. It makes good sense to use GiB when appropriate, with the recommended link for Joe's enlightenment - if people are desperate to use GB, it could be a piped link as GB, but it's probably preferable to openly use the IEC designations with links. Current guidance stands. ..dave souza, talk 18:04, 10 March 2006 (UTC)

Actually, I would be willing to support a piped link as a compromise. Earlier, I was going to mention linking KB/MB/GB/etc when used in a binary context to a page that explains the different meanings, but I forgot. That's a good idea. Jgp 20:28, 10 March 2006 (UTC)

"Common usage" isn't common, anyway. Your decimal-sized hard drive is chopped up into a decimal number of binary chunks by the operating system, transferred by your decimal-speed CPU to your binary-sized memory over its decimal-rate bus, then moved across a decimal network connection to your friend who burns the files with binary-reported file sizes onto a decimal-sized DVD or a binary-sized CD.

This isn't a case of everyone in the universe using one meaning consistently and being opposed by a small group of purists. (And no, the NIST, IEEE, IEC, BIPM, ANSI, and ISO are not "a small group of geeks and pedants".) The distinction might not be important to programmers, who only work with binary memory addresses, but it's certainly important to anyone burning files to a CD, coding on an embedded processor with a limited amount of memory, measuring web server bandwidth, or designing telecommunications systems or computer peripherals. This is an encyclopedia; accuracy and standards trump sloppy trade-specific jargon. — Omegatron 06:17, 11 March 2006 (UTC)

Also, can you all look at {{quantities of bits}}, {{quantities of bytes}}, {{Bit rates}} and um... I guess there's no place to talk about it as a group, but a user suggested we merge all the articles like kilobit, mebibyte, and so on into bit and byte. We had that discussion a while ago on Talk:Binary prefix, and the decision was to keep them separate but tie them together with a navigational template, but it's come up again. — Omegatron 07:38, 11 March 2006 (UTC)

I imagine this is probably an example that stirrs up ivory tower rebellion syndrome, but the SI system has such power because it is entirely unambiguous. The misuse of these prefixes is jargon, and not frequently understood outside technical circles. In speech, the terms are almost never used more precisely than "about a million bytes". As an encyclopedia, we should not use jargon, and we should not be ambiguous. —Daelin @ 2006–03–18 09:28Z

As an example of how ambiguous this mis-usage of "kilo-" is, consider the telecommunications industry. Here, in this context, "kilo-" always means 1000. A 56k modem has a 56,000 kilobits per second transfer rate. A 4mbit pipe is 4,000,000 bits per seconds. Your download speeds are "in context" reported in powers of the factor 2^10. Your DVDs all follow SI/ISO standards of 10^3 usage, and the on-screen statistics you can enable on most DVD players also always follow SI/ISO usage. These are all "lay" computer contexts where the "common" 2^10 usage does not apply, but the international 10^3 usage does.—Daelin @ 2006–03–18 09:46Z

Just voicing my strong support for keeping the policy as it currently is. The IEC came up with a solution to this old ugly misuse of SI prefixes, and the IEEE is currently considering officially adopting the IEC prefixes as well. I think IEC and IEEE support are more than enough reason for us to use them. Also, see the above comments about the average lay reader simply ignoring the 'i'. The only readers that have a problem with us adopting IEC prefixes are usually those who are somewhat computer literate but don't fully grasp the problem with incorrectly using SI ten-power prefixes; linking the prefixes (or the first few examples) solves this problem for most people. Then of course we have the camp of editors who subscribe to the theories that the prefixes "sound silly", "are dumb", or "it's okay to incorrectly use SI prefixes". Whatever the case may be, the IEC binary prefixes are unambiguous, and thus are more accurate to use in certain contexts. The current policy is a reflection of that, and it should stand. -- uberpenguin 15:03, 18 March 2006 (UTC)

The IEEE has officially adopted them. — Omegatron 16:55, 18 March 2006 (UTC)

You're right. I did a little research that will hopefully put a dent in the wild claims that IEC prefixes aren't supported by computer professionals. How about a list?

• • • IEC: IEC 60027-2
    • IEEE: Approved the trial adoption of the IEC binary prefixes in 2002. In part, it states "The SI prefixes shall not be used to denote multiplication by powers of two." ([3] page 5). In March 2005 the IEEE standards board unanimously voted to upgrade this adoption from trial-use to full-time use. [4]
    • NIST: NIST's 2001 publication of the official US interpretation and usage of SI recommends against the usage of SI prefixes to refer to binary multiples. Regarding the IEC prefixes, a note states: "Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes." ([5] page 24)
    • ANSI: Affirmed the aforementioned IEEE proposals in April 2005. ([6] page 7)

Note that most of the linked documents state in no uncertain terms that it is incorrect to use SI prefixes to describe binary multiples. Can we give the tired "not adopted" and "not used" arguments to rest? -- uberpenguin 00:57, 19 March 2006 (UTC)

I made that list at Talk:Binary_prefix#Organization_recommendations a while ago.  ;-) Feel free to add to it. This site has a list, too: IEC prefixes and symbols for binary multiples — Omegatron 00:46, 22 March 2006 (UTC)

when to use commas using dates in a paragraph

Our records reflect that Mr. Lussier initially contacted us on June 26, 2008 to disconnect his service as of July 5, 2008 for lines ending in 6594, 6549 and 6547. On July 5, 2008, Mr. Lussier lines were disconnected and early termination fees was charged for mobile ending in 6549 and 6547. However, on August 10, 2008 Mr. Lussier contacted us to reconnect the mobile ending in 6494 which was not charged the early termination fee due to disconnecting this line. When an Alltel customer ports their number away from Alltel to another carrier while under contract, we will waive or credit the early termination fee if the customer reactivates their service with us within 30 days. Our records do not reflect that Mr. Lussier ported his number to another carrier.