This poll deals with issues regarding date linking/unlinking and the use of autoformatting (software that automatically changes the date format displayed to logged-on editors' set preference). The poll runs from 00:00, 30 March 2009 (UTC) and concludes 23:59, 13 April 2009 (UTC).

The history of the dispute

After a long debate at

• Wikipedia:Manual of Style (dates and numbers)/Three proposals for change to MOSNUM
• Wikipedia:Manual of Style (dates and numbers)/Date Linking RFC

Although these RFCs offered guidance on several points, there is disagreement as to whether that guidance has resolved all aspects of the debate. There have also been claims of an inherent bias in the wording and structure of the questions. This RfC seeks to clarify (i) whether a form of date autoformatting is desired, and (ii) whether the linking of date fragments should be used, and if so under which conditions.

Poll

The poll will commence on 30 March 2009 and will run for two weeks. Users are encouraged to review the proposals and vote in all three sections: Autoformatting, Month-day linking, and Year linking. After the poll has closed, there will be a two-week period for discussion. A second poll in late April will then be considered—if necessary—to look at how the results of the first poll will be implemented. Whilst comments from individual parties are extremely welcome, any threaded discussion will be moved to the talk page.

Background statement

Does the Wikipedia community support the concept of date autoformatting?

Scope Autoformatting is a way of marking up dates to allow registered users to choose their preferred display format. A variety of methods have been proposed by which this might be implemented. The question posed here is whether the community desires the basic, common elements of autoformatting.

What is a date format? Two main date formats are used by English-speakers: March 11, 2009 (MDY, mainly in North America) and 11 March 2009 (DMY, mainly elsewhere). Other date formats are less commonly used in running text, but frequently used as input parameters to templates: 2009-03-11 (YMD an ISO-style format).

What is date autoformatting? It is a system that allows dates displayed in articles to automatically change to reflect a registered user's settings under "Special:Preferences/Date and time"; unregistered users (IPs) cannot access the preference settings. The existing autoformatting system (Dynamic Dates, outlined here), introduced in 2003, requires use of the double-bracket link syntax to identify dates for autoformatting.

A recent update to Wikipedia's software allows dates to be autoformatted through the use of a function ({{#formatdate}}) instead of with the link-based markup ([[30 March]] [[2009]]). This function displays autoformatted plain-text dates per a registered user's preferences, without links ("30 March 2009"). It adds the option of defining a default date format for unregistered users and anyone who has not set a preference. As with the original system, all dates in an article would require markup to guarantee consistency.

What happens if autoformatting is accepted? Consensus will be sought on specifications, which will then be used by developers and editors to establish a system based either on a modified version of the existing software or on a new markup or template scheme; dates will be marked up accordingly.

What happens if autoformatting is rejected? The markup used by the previous system will continue to be removed, and any dates that are inconsistent with the overall format for their article will be corrected, manually or using automatic means.

Statement for

Date autoformatting is about giving users more options. It allows users to exercise personal control over the way in which dates are presented. This is not a new concept; Wikipedia's existing system has been in use since 2003, and personalized date formats have been an option in operating systems for decades. It is a natural extension of the trend toward increased user choice in how we interface with our computers, iPods, mobile phones, and every other type of personal technology.

Beyond that goal, autoformatting enhances our ability to present a consistent date format. At present, the Manual of Style allows dates to be formatted in either DMY or MDY style, based on regional usage and editorial consensus. The absence of a standard format creates situations where pages are individually consistent, yet stylistically at odds when considered as a collection of articles. This differs from other encyclopedias, which employ a consistent format across the entire publication.

Much has been made of the supposed complexity of autoformatting, but the reality is that Wikipedia's editors have been using date markup for almost six years now. Yes, dates do require special formatting to enable the feature – but this is no different from what is required of virtually every display option on Wikipedia. Markup enables us to enhance the presentation of articles, from the most basic options such as bold and italic text or section headers to more complex features such as templates and tables. Any large-scale changes can be automated through the use of existing editing tools. As for the impact on novice editors, Wikipedia has never expected them to master every aspect of the interface. In fact, new users have always been encouraged to contribute without worrying about spelling, grammar, or formatting options.

Currently, ongoing discussions between editors and Wikipedia's developers are focusing on ways to resolve concerns expressed about the existing system, chief among them the links and what unregistered users see. These issues are being addressed through the active development of an improved system, elements of which have already been incorporated into the system software. Other options under consideration would add enhancements that improve control over site-wide standards while allowing individual articles to be tagged with page-specific default date formats where desired. Looking down the road, date markup has also been identified as central to the development of new features such as automated time lines, automated "this day in history" pages, and enabling improved efficiency with database dumps. Autoformatting would also replace the current need for "dateformat" parameters in templates.

The benefits are obvious for readers and editors alike. Date autoformatting allows greater consistency in how our articles are presented to all readers, it assists editors in presenting a uniform, professional look, and it gives registered users the option of personalizing their interface. In short, this discussion is about offering increased choice to all of Wikipedia's users.

Statement against

There is no problem to solve. Whether day or month comes first (3 January; January 3) is trivial—all English-speakers recognize both; the US military uses DMY, as do many Canadians; by contrast, many publications outside North America, including newspapers, use MDY. Given this mixed environment, it is unlikely that readers even notice, let alone care, which format is used in an article.

MOSNUM already has simple, well-accepted rules for date formatting, which require no markup. In the context of attempting to achieve a simple solution, WikiMedia's Chief Technical Officer, Brion Vibber, has stated: "My personal recommendation would be to remove all date autoformatting …".
Metadata fallacy. Markup is unnecessary to produce metadata. We already have powerful search tools, including the much-underused Wikipedia-constrained google search (site:en.wikipedia.org), and category searches. For markup to be useful, an option would be needed to enable editors to see all marked-up dates as though linked—another layer of complexity; What links here for a date or year page produces a list of thousands of articles whose only common factor is that some event, related in some way to the topic, happened on that date or year; such low-quality metadata is virtually worthless to editors of future time-based projects.
Development risks. The failure of the original autoformatting was largely due to the ad hoc imposition of a design by programmers acting without agreed specifications (clear objectives) by the community. The so-called fixes suggested are of limited scope and functionality, and have not been agreed to by the community. We should not risk allowing solutions to be tacked on bit by bit over the next few years, requiring increasingly complicated syntax even further remote from the average editor. Among these issues would be non-breaking spaces, AD/BC, slashed, ISO and Gregorian/Julian dates. Date ranges

—avoiding the clunkiness and forced repetitions that the original system involved—would be a significant challenge.

Autoformatting responses

Please remember before adding your opinion that this section deals with the autoformatting of dates, not date linking.

Please indicate your vote under ONE option, accompanied by a concise explanation for your choice. Your explanation is important in determining the community consensus.

I support the general concept of autoformatting

1. Support. While I don't care much about having a user preference to make all dates into one format, something like {{#formatdate}} combined with a {{DEFAULTDATEFORMAT}} magic word to set the default for the whole page is necessary to avoid either forcing all date-handling templates to have a "dateformat" parameter on every use or forcing all date-handling templates to allow any arbitrary garbage in their "date" parameters and forgo any possibility of date manipulation. I also see no point in not allowing those who want the feature to have it, and frankly the "arguments against" above reek of
   logical fallacy with no real substance. Anomie⚔ 23:14, 29 March 2009 (UTC)[reply
   ]
2. Support. I find it much nicer and easier as a reader to have dates autoformatted into a single style. I find shifting formats much more distracting than spelling variants like -or v. -our or -ize v. ise. Eluchil404 (talk) 00:01, 30 March 2009 (UTC)[reply]
3. Support. I support partially per Anomie, but also because marking up dates with metadata lets us do interesting things that we can not do otherwise. Too many of the arguments against autoformating are actually against datelinking. dm (talk) 00:02, 30 March 2009 (UTC)[reply]
4. Support. I set my date preference to display dates in U.S. format, so I expect dates to display as such. Also, autoformatting helps prevent edit warring.-Jeff ^(talk) 00:04, 30 March 2009 (UTC)[reply]
5. Support per above. I prefer US format at all times. Unlike other cultural differences (such as UK vs US spelling), this is something which can easily be implemented, as that's how it's been done. Last month, I was partially involved in a rather silly feud in whether to use one format or the other. I think it left some people unwilling to contribute anymore. That is totally unnecessary IMO. --♬♩ Hurricanehink (talk) 00:51, 30 March 2009 (UTC)[reply]
6. Support. Agree with Anomie, I think much of the issue would be fixed simply by setting a different default (currently the default is to not format it all, resulting in inconsistency) that would be seen by anons and new users. I believe it would be a simple configuration change. Mr.Z-man 00:59, 30 March 2009 (UTC)[reply]
7. Support Autoformatting could be useful when moving templated citations from one article to another: one could copy or share the citation without having to change its date formats. It seems less useful in main text, but for citations it seems worth having. Eubulides (talk) 01:27, 30 March 2009 (UTC)[reply]
8. Support autoformatting without autolinking. (This nullifies most of the "Oppose" !votes.) Makes it easier to maintain a consistent date format within an article and may make it easier to collect metadata. — Arthur Rubin (talk) 02:05, 30 March 2009 (UTC)[reply]
9. Support - it doesn't matter to me overmuch, but painful experience says that we will be flooded with complaints if we don't do this. However, any autoformatting solution should not result in automatic linking, should allow linking intentionally, should allow casual readers to set a viewing preference (this doesn't mean Special:Preferences especially, just a way to set a cookie), and should allow per-page setting of "correct" (per topic/location) defaults for date display. If we don't do all of these, we'll just come back to the whole ugly fight again. — Gavia immer (talk) 02:46, 30 March 2009 (UTC)[reply]
10. Support, per Anomie and Gavia immer.-gadfium 03:20, 30 March 2009 (UTC)[reply]
11. Support, not necessarily with auto-linking, although proper handling of metadata is possible without this, it facilitates the process. The move to formatted articles with reusable data is a necessary development generally. Given the number of wikignomes and the ingenuity of bot programmers, there should be no great difficulty in implementing it. DGG (talk) 03:31, 30 March 2009 (UTC)[reply]
12. Support, especially given that the developers have already added the capability for link-free autoformatting to the system. Many of the other concerns expressed against DA can easily be addressed; for example, the "#formatedate" expression can easily be invoked through the use of a template with a much shorter name, such as "{{D}}". It is also a means to present a more professional look, as opposed to the mix of formats we now offer. (The multiple-date-format guideline is at odds with most other professional publications, which choose one or the other; when viewed as a collection, our articles appear inconsistent. When was the last time you saw Britannica or the Times use a mix of DMY and MDY?) --Ckatz^chat_spy 04:33, 30 March 2009 (UTC)[reply]
13. Support, per Eluchil404. I would also support a spelling regionalisation autoformatting. AKAF (talk) 06:58, 30 March 2009 (UTC)[reply]
14. Support. Before autoformatting was introduced, there were lengthy rows about how to format dates. This seems recently to have come back, just as some started delinking dates. -- User:Docu
15. Support. Autoformatting makes sense for the reader. I'd probably have voted against if the link-free option were not available, though. YLee (talk) 09:17, 30 March 2009 (UTC)[reply]
16. Support. Please leave as is (or was). This, that and the other _[talk] 09:31, 30 March 2009 (UTC)[reply]
17. Support. With the understanding that the autoformat feature prevented debates and potential conflicts over date format. --Born2flie (talk) 09:36, 30 March 2009 (UTC)[reply]
18. Support The possibilities of metadata of dates. Joy. There will still be no compulsion to special format dates, plus what bots undid, surely they can redo. Spurious arguments don't wash. -- billinghurst (talk) 10:23, 30 March 2009 (UTC)[reply]
19. Support for all the reasons given in the advantages, this is far too simple to be considered "complicated" as those opposing would wish us to think. —Locke Cole • t • c 10:53, 30 March 2009 (UTC)[reply]
20. Support. Using this feature is hardly a burden on editors (I use it all the time for dates I add), and is a handy way to resolve perpetual US vs UK date format edit warring. Strongly opposed to the unilateral delinking campaigns by bots and other editors. --DAJF (talk) 11:44, 30 March 2009 (UTC)[reply]
21. Support. The environment may be mixed but Wikipedia is a single unified project. I can live with reading mis-matched date formatting, even if on the same article, but it would be better if all of Wikipedia adheared to a standard.  æron phone home  12:42, 30 March 2009 (UTC)[reply]
22. Support. Formatting for dates is minor, but it is very important to have a standard format across the whole project.--Unionhawk (talk) 12:58, 30 March 2009 (UTC)[reply]
23. Support. Per DAF. I was one of the user who objected to the "unilateral delinking campaigns by bots and other editors", and was treated quite rudely by the other side, with odd accusations of "elitism" being hurled, among other things. There seems to be some deep-rooted reasons against autoformatting that have nothing to do with autoformatting itself. I'm glad to finally see a project wide poll on this, though I am at a complete loss as to why this was not done first! I also support measures to ensure that dates are displayed consistently to unregistered users. -
    talk) 13:03, 30 March 2009 (UTC)[reply
    ]
24. Support. The general formatting of all dates gives a consistent output for all articles. The improvements proposed in the software to allow/not allow the date to be linked when autoformatted makes it an even more attractive solution so that people do not have to worry about what is actually in the article text they see it the way they want. Keith D (talk) 13:26, 30 March 2009 (UTC)[reply]
25. Support - the benefit gained from consistency across articles outweigh the potential problems in my opinion. Camw (talk) 13:36, 30 March 2009 (UTC)[reply]
26. Support - At the end of the day it is so much easier to read the dates when they are presented consistently across all articles. It will stop people editing articles to change the date to their personal preference, which I often see. Most importantly, wikipedia is about providing articles for the reader, not about providing a hobby for editors, as such arguments about extra key strokes and technical reasons are a bit mute. Martin451 (talk) 14:02, 30 March 2009 (UTC)[reply]
27. Support, if only to easily enforce consistent date formatting on an page (I don't have date preferences set myself). If the formatting function has shorter syntax like {{#date:...}} it will be easy to use, easy to understand, will make transcluding templates with dates in them easier, and only one person has to worry once about the proper date format on a given article instead of every editor who adds a date. --Amalthea 14:17, 30 March 2009 (UTC)[reply]
28. Support. I'm a user of this – ISO dates for me, please – and I'll miss it if it goes. The statement against does nothing to make me think otherwise. — the Sidhekin (talk) 14:51, 30 March 2009 (UTC)[reply]
29. Support, date autoformatting can provide a consistent look across articles for users with either preferences or a default. This feature has been around and used, albeit unfortunately tied to date linking previously. Technology concerns can be overcome once agreed upon as a feature and the community decides on exact behaviour and markup. Additionally, feature facilitates easier use of citation templates. —Ost (talk) 14:56, 30 March 2009 (UTC)[reply]
30. I want date and time to be displayed as I like. --Morten (talk) 14:59, 30 March 2009 (UTC)[reply]
31. Support — Bellhalla (talk) 15:05, 30 March 2009 (UTC)[reply]
32. Support - I support for various reasons. 1) For users that don't all look at dates the same way 2) Because it saves extraneous codes (not a lot, but it can add up, trust me). Plus, when the autoformatting was removed, we were left with dates in articles that looked like this (2007-02-03 or 2007-30-11). I think it was ill planned when it was first removed to begin with.  BIGNOLE  (Contact me) 15:15, 30 March 2009 (UTC)[reply]
33. Support - Autoformatting without wikilinking seems to be a good solution to me. --TreyGeek (talk) 15:44, 30 March 2009 (UTC)[reply]
34. Support the general concept but not the way it was implemented. I think autoformatting without wikilinking, and somehow bringing in either user date preferences or region preferences rather than just relying on 0.5% of readers changing their settings and the rest of us assuming they have. Orderinchaos 15:59, 30 March 2009 (UTC)[reply]
35. Support autoformatting without autolinking, mainly for its use in metadata. However, I will consider removing my date preference so I can see pages as IPs see them, even if the default format is not my favourite. Certes (talk) 16:02, 30 March 2009 (UTC)[reply]
36. Support autoformatting because there needs to be consistency because it is sometimes confusing if you mix them up, say 03/03/2009 means the third day of the third month of year 2009, and occasionally I do get confused. DeMoN2009 16:14, 30 March 2009 (UTC)[reply]
37. Support - While I recognize that virtually all English speakers recognize a date in any common format, date formatting is an issue that rarely occurs to editors, and it does look sloppy to have various different formats in one article. --Skeezix1000 (talk) 16:26, 30 March 2009 (UTC)[reply]
38. Support. I can't help feeling this wouldn't even be an issue had the #formatdate implementation come first, rather than overloading this function onto linking. Frankly, I didn't know #formatdate existed until I saw this poll, but I always thought something like this was the best approach. I have generally delinked dates in the past in the course of doing other edits to articles; now I can reformat instead. This is progress. Rklear (talk) 16:48, 30 March 2009 (UTC)[reply]
39. Support. Readers may well be familiar with both "3 February 2009" and "February 3 2009" (and I have no strong preference for either format), but auto-formatting can help avoid the abominations that are "3/2/09" and "2/3/09", both by formatting as either "DD MMM YYYY" or "MMM DD YYYY" (i.e. not "DD/MM/YY" or "MM/DD/YY") and by encouraging editors to specify dates using the template. Consistency throughout an article is a big plus, and the option for readers to see date formats based on their browser or OS locale is a bonus. In the future auto-formatting could even be used to wikilink months and years, making dealing with the outcome of the two discussions below relatively trivial. Cheers,
    propaganda_deeds 17:14, 30 March 2009 (UTC)[reply
    ]
40. Support. I agree with flag's point above. It's much faster for me to see the dates in a way that I see everyday and can recognize. Grk1011/Stephen (talk) 17:20, 30 March 2009 (UTC)[reply]
41. Support as I found it very useful and interesting to be able to click a date and see what other events happened then. Yes, there were (and still are) a lot of articles linked to specific dates (as happens in a world with a long history), but I think that argument is irrelevant. All this worry about articles having too many links to them is pointless worry as we will have more and more articles linked to each other as the encyclopedia grows. Are we going to start limiting the number of links which can be placed into articles when we reach 5 or 10 million articles just so we don't have "too many links" to any given article? That's just absurd. We're going to have to accept that many articles on main topic are going to have hundreds, thousands, and perhaps tens of thousands of links to them. In the case of dates, it's likely they will be on the high end of things, but that's what happens when an online encyclopedia grows. And the argument that someone is going to have to go put back the links that someone removed is absurd. Just run the same bots again, only in reverse. It certainly won't be any more difficult than it was to remove them all. I also think the date formatting part is very helpful, and it wouldn't be difficult to set the default for anonymous users (and those who haven't changed it) to something like "3 June 1934". ***日本穣^{? * Talk to Nihonjoe} 17:37, 30 March 2009 (UTC)[reply]
    1. Making additional comments as SIllyFolkBoy doesn't seem to think my comments above are focused enough. Autoformatting would be extremely useful (as I pointed out above) in order to create a consistent formatting for dates, and it wouldn't be difficult to set the default format to something which is useful to everyone (such as the example I gave above. As I think the easiest way to implement this is the already existing date linking using square brackets, I included the comments regarding the usefulness of doing that, as well as my opinion on the absurdity of the "but it creates too many incoming links to the article" argument. ***日本穣^{? * Talk to Nihonjoe} 19:13, 30 March 2009 (UTC)[reply]
42. Support. Providing a consistent date format would be beneficial to the look of articles and wikipedia. Presumably IP tracing could also be used to provide MDY for North American readers and DMY for others even if not registered users. It would also negate the need for date linking as a way to autoformat which dilutes wikilinks and is generally of little use. Please at least implement the code so there is the option of using autoformat which can be determined, as with reference styles, by consensus on individual articles. |→
    GMT
    )
43. Support I am a US user who reads and edits mostly US articles, but I hate the US standard for date formatting, much preferring the European standard. It's nice that Wikipedia can offer everyone the option to format dates as he prefers. I think the system was working fine until someone got a bee in his bonnet about "unnecessary" links. Ntsimp (talk) 18:27, 30 March 2009 (UTC)[reply]
44. Support giving user a choice. davidwr/(talk)/(contribs)/(e-mail) 18:31, 30 March 2009 (UTC)[reply]
45. Support it's worth having it there as an option. I would note that removing autoformatting from featured articles wasn't debated - it was simply done. I voiced opposition then, on the basis that it didn't improve things, but got the feeling that it wasn't worth pushing for. Since then, it's been _a single_ user pushing it. That said, a system that is totally automatic would be much better, particularly if it could also handle timezones (which is a much bigger issue than date formatting). Mike Peel (talk) 18:54, 30 March 2009 (UTC)[reply]
46. Support autoformatting. I prefer DMY, don't really mind MDY but I really hate YMD format. It is just so ugly and looks unprofessional to my eye. Mjroots (talk) 19:10, 30 March 2009 (UTC)[reply]
47. Support per
    User:This flag once was red --Cybercobra (talk) 19:47, 30 March 2009 (UTC)[reply
    ]
48. Support. Simply better. Ideally choosable via (in order of priority) (i) user option (ii) article option (iii) site-wide default & others. Mr Stephen (talk) 19:51, 30 March 2009 (UTC)[reply]
49. Support. I think the autoformatting is good but if there is a problem with the software allowing users to choose which way they want to see the date displayed then the developers should fix it so we can stop voting on it--
    talk) 20:07, 30 March 2009 (UTC)[reply
    ]
50. Support This removes the potential complication of later trying to unify the styles so that all dates are uniform. Why have them appear differently on different articles, or try to agree on one method (which would never happen), when we can make it a user preference? JeremyMcCracken (talk) (contribs) 20:18, 30 March 2009 (UTC)[reply]
51. Support- Why not let users choose how dates are displayed? --Jackieboy87 (talk * contribs) 20:25, 30 March 2009 (UTC)[reply]
52. Support, tho MediaWiki automatically formatting dates with extra markup would be better, with nowiki for exceptions. -- Jeandré, 2009-03-30t21:23z
53. Support the benefits of automated time lines/this day in history pages could be big. Brandonrush Woo pig sooie! 21:26, 30 March 2009 (UTC)[reply]
54. Maybe I'm OCD, but I put a high emphasis on customizability as an integral part of usability. The new software update provides a great middle ground. –Sarregouset (talk) 21:27, 30 March 2009 (UTC)[reply]
55. Support though I don't think it's a big deal. Should be automatable enough not to be a big burden. Offers scope for (e.g.) searching for every article that references a particular date which, despite the handwaving in the Statement Against, doesn't currently appear to be possible. Consistency for readers is good. Gareth McCaughan (talk) 21:32, 30 March 2009 (UTC)[reply]
56. Support. Wikipedia should be written for the readers, and providing logged in users with a consistent display of dates enhances their experience without detracting from the information provided to a non-logged in user as they would still see consistent formatting within an article. -- Whpq (talk) 21:44, 30 March 2009 (UTC)[reply]
57. Support. I'd prefer to have autoformatting without autolinking, but I'll take it either way. RossPatterson (talk) 22:08, 30 March 2009 (UTC)[reply]
58. Support. Consistency and reader customisability are important factors here. Julianhall (talk) 22:16, 30 March 2009 (UTC)[reply]
59. Support. Being a web programmer involved in many
    i18n debates myself, any way to provide users (readers moreso than editors) consistency in displayed data is helpful. --MikeVitale 22:38, 30 March 2009 (UTC)[reply
    ]
60. Strong Support With the new parser function and the possibility for a default, the main reasons for opposition are solved. In addition, there is no reason why we should provide anything less than the most convenient viewing experience possible Alexfusco⁵ 23:59, 30 March 2009 (UTC)[reply]
61. Support. I'd rather have the possibility to choose the date format that I'm most familiar with.--Le Petit Modificateur Laborieux (talk) 01:12, 31 March 2009 (UTC)[reply]
62. Support Convenience. Also, it keeps the same style as before...autoformatting is helpful. Daniel Benfield (talk) 01:15, 31 March 2009 (UTC)[reply]
63. Support autoformatting, it's important for collections of articles to be consistent in date formatting, and the current method allows awkward mismatches between articles. Autoformatting also allows user preference, making Wiki more universal and less centric on the culture of the article's editor(s). Chuckiesdad/Talk/Contribs 01:56, 31 March 2009 (UTC)[reply]
64. Strong Support Consistency within and across articles and user choice are important to many people. If it is not important to you, then why are you voting at all? hulmem (talk) 03:13, 31 March 2009 (UTC)[reply]
65. I also support autoformatting without autolinking. shoy (reactions) 03:33, 31 March 2009 (UTC)[reply]
66. Support needed for reliable semantic data retrieval
    talk) 06:10, 31 March 2009 (UTC)[reply
    ]
67. Support: Despite my fear of the effort involved to implement the system, I like the autoformatting proposal as a way to help readers. To the best of my knowledge, printed encyclopedias don't flip flop between date formats, so why should Wikipedia? (Apologies for lumping the different types of encyclopedias into one category) If you have any questions, please contact me at my talk page. Ian Manka 06:13, 31 March 2009 (UTC)[reply]
68. Support: Localisation and personalisation is the future. Wikipedia needs to get on board. — D. Wo. 06:38, 31 March 2009 (UTC)[reply]
69. Support More based on the conformity and uniformity argument than anything else. bahamut0013^words_deeds 07:01, 31 March 2009 (UTC)[reply]
70. Support. Autoformatting is a good thing, especially because most editors refuse to write dates in the format I find easiest to decode. With autoformatting all can be happy at the same time. Seriously, who could object to that? Most of the "oppose" votes here seem to argue against the linking of dates, which is indeed disturbing, but is not what this poll asks about either. –Henning Makholm (talk) 11:00, 31 March 2009 (UTC)[reply]
71.  – 
    iridescent 13:03, 31 March 2009 (UTC)[reply
    ]
72. Support. Autoformatting is neutral in appearance, while being adaptive to users who do want a preference in date style.GraemeLeggett (talk) 15:39, 31 March 2009 (UTC)[reply]
73. suppoet Bubba73 (talk), 15:52, 31 March 2009 (UTC)[reply]
74. Support Used to work transparently and effectively to give logged-in users the date preference of their choice. --
    Old Moonraker (talk) 16:18, 31 March 2009 (UTC)[reply
    ]
75. Support I think that date linking/metadata is by far the most interesting aspect. Getting a uniform date format would be a nice bonus, and lets support the Buddhists! The arguments against read like Luddite propaganda, of course the template should be as user friendly as possible. I don't really understand the argument against ISO what is so hard about 20090331? No seriously. Unomi (talk) 16:31, 31 March 2009 (UTC)[reply]
76. Support. Avoid arguments over which format to use for a particular article. Bluewave (talk) 16:54, 31 March 2009 (UTC)[reply]
77. Support. A date is an essential element to record and archive data, information, and knowledge. Format is an important aspect for time and date stamps. The format should be consistent across the community. After all, are we not a community? Unfortunately, many of the arguments against are not persuasive; these appear more like anarchist propaganda versus constructive comments or opinions about the topic under discussion. If we, as a community, are unable to set a basic expectation for dating records, then why do we have all the other rules and guidelines in place? PatientSafetyGuru (talk) 17:31, 31 March 2009 (UTC)[reply]
78. Support. It is essential we get this consistent to avoid something like 1-2-2009/2-1-2009 which is ambiguous. A lack of standardization is just sloppy and makes articles appear to lack any credibility. Given the power of wikibots, auto formatting everything should not be an excessively difficult undertaking.--Analogue Kid (talk) 17:54, 31 March 2009 (UTC)[reply]
79. Support. This is the way to do it, because it is very effective.
    talk) 18:09, 31 March 2009 (UTC)[reply
    ]
80. Support. I understand that it might be a pain to reconfigure pages using templates or parser functions, but I don't think that's a reason for limiting a users choice. Couldn't a bot be written to do this anyway (or maybe written into AWB)? And is typing 10-20 extra characters really that big a deal?
    talk) 18:40, 31 March 2009 (UTC)[reply
    ]
81. Support. It shouldn't be beyond the wit of man to allow date auto-formatting. Also, any opposition with rationale given against date linking should be disregarded; we shouldn't be counting the votes of people who've clearly demonstrated that they don't understand the proposition. The argument that there's no problem to solve is something of a
    non-sequitur too, if all you're saying is that you personally aren't that bothered switching between different date formats then that's not a reason to block the choice of others. Objection on the basis that it causes you more work is possibly valid if you really feel you can't be doing with the extra keystrokes. Personally, I'd prefer a shorter syntax than e.g. {{#formatdate|March 31, 2009}}, something like {{d|2009-03-31}} could work, as others have suggested. --SallyScot (talk) 19:53, 31 March 2009 (UTC)[reply
    ]
82. Support. For the price of four brackets ([[ ]]) around dates and no more than ten hours of programming time from an experienced PHP developer (I know this because I already wrote the code once) we can have consistent date formats across the project, the ability to have per-article defaults that override the site-wide default, support for date ranges, and the ability for registered users to specify their date format and date linking preferences independently of each other. This would completely eliminate the need to ever argue about date formats or date linking again, and allow almost everybody to have what they want. --UC_Bill (talk) 20:34, 31 March 2009 (UTC)[reply]
83. Strong support. Date formatting should be seen as an obvious first step towards the more general goal of showing Wikipedia readers article content presented in the way the individual reader finds most useful. We ought to do this for something as small as date formats now. We could do this for something as large as English language spelling variations. We should hope to one day be able to do it for much more than that. (sdsds - talk) 20:36, 31 March 2009 (UTC)[reply]
84. Support Standards are a wonderful thing - problem is there are so many to choose from - Now we have the solution to one instance of that problem - date auto formating ;)
    talk) 21:44, 31 March 2009 (UTC)[reply
    ]
85. Support Its really confusing if you're editing an article in one format and your display is in the other format
    talk) 21:55, 31 March 2009 (UTC)[reply
    ]
86. Support But please, let's all support whatever we decide, and leave it that way. This is a monumentally boring topic. We should all get back to writing and researching. ---- CharlesGillingham (talk) 22:51, 31 March 2009 (UTC).[reply]
87. Support Letting users see dates as they prefer adds to the user-friendliness of Wikipedia. I also note that many of the opposing votes are complaining about links and the "sea of blue", which are irrelevant to the proposed solution, and should therefore be discounted. -- Arwel Parry (talk) 22:57, 31 March 2009 (UTC)[reply]
88. Support User (i.e. reader) preferences should take priority over editorial decisions. I'd rather that date formats (and linking) be specified in preferences, than dictated by a small group at MOSNUM. --Sapphic (talk) 00:02, 1 April 2009 (UTC)[reply]
89. Support No brainer. Don't interrupt the scan of the article w/ speedbumps like oddball (to the reader) formats. --Kbh3^rdtalk 01:22, 1 April 2009 (UTC)[reply]
90. Support, surprising myself after some thought. Initially, I was bothered only by the deletion of existing markup, since the "KISS" and "There's no problem to solve" arguments are compelling, and the existing applications (auto-linking to a page about that year, or a page about that date, allowing registered users to choose their date display format) are of dubious merit. But the idea that this metadata might have some future use is tantalising:

    • There is a difference of both performance and quality between a search using a parsing algorithm (i.e., one trying to recognise data by pattern-matching the data itself) and one using metadata. Something that has been marked by a human editor as a date is more informative, machine-wise, than it's own guesswork as to what might be a date. This is true even if the text so flagged doesn't follow any standard convention beyond being humanly readable as a date. If <tag>Oct 18 45</tag> is allowed, as well as <tag>Eighteenth of October, 1945</tag>, and even <tag>in October of that year</tag>, the existence of the tags does nothing to detract from the presented data, and allows the development of future applications which might well present useful data to the user. Consider, for example, a parser which was able to resolve that last example, from the article context, as being a date concurrent with the first two - that might be a useful research feature, and one whose operation could only be helped by date tagging. Or imagine a historical article in which the author finds it useful to use the early, local calendar in order to relate the sequence of events. If each date is tagged, an application might offer automatic pop-up conversions of each date into other relevant calendars.
    • The argument that most current users don't see any difference is relevant only to the existing applications, which nobody seems to think useful. If a future application can exploit this metadata to useful purpose, such an application might become part of the standard interface, rather than being optionally configured on a per-user basis.
    • Whilst date tagging as described above would be potentially machine-useful whilst being mostly user-neutral, far MORE machine-useful would be the addition of a field to the tag specifying the date in a standard format, whilst the enclosed text continues to display as written. This would allow bot-tagging without affecting primary content (e.g. quotations), and allow existing proponents of the optional autoformatter to continue to play with it.
    • There needn't be a requirement that all, or indeed any dates are tagged in an article, and as long as no "killer app" appears which makes editors want tagged dates, it's possible that most articles won't have any which aren't inserted by bot-tagging. With the appearance of such an app would likely come a surge of retrospective date-tagging.
    • Of course, the duplication of the date in the tag involves the risk that the two dates may end up different, but this strikes me as nothing new to Wikipedia editors - almost every fact in the encyclopedia can be found in more than one place, and in many cases in hundreds of different articles. Avoiding the possibility of inconsistency is neither a realistic, nor a necessary aim.
    • The extra work involved in creating pages shouldn't be a problem: editors unconvinced of the worth of date tags may simply omit them. Provided their choice of format isn't too obscure ("on the third moon after Michaelmas, in the year of the long winter"), it shouldn't be too difficult for subsequent editors and bots to add them, should they desire.

    Nyelvmark (talk) 01:30, 1 April 2009 (UTC)[reply]

91. Support - I'm from Australia and prefer to see dates in the DMY format. If there's a way to autoformat all dates according to each user's preferences, then I think that's a great idea.
    Wcp07 (talk) 05:23, 1 April 2009 (UTC)[reply
    ]
92. Support This is a real issue within Wikipedia that has already led to ArbCom for several users. I find it to be far easier to make a rule to have the dates appear in a consistent manner than to allow, well, sometimes format A and sometimes format B because there will always be gray areas. Specific guidance will reduce problems if we'd just all agree on a standard format to use. I have no preference in any particular way. That said, allowing personal settings to determine the presentation of the material would be the next best step. The primary reason I'm responding though is that the issues brought up in opposition. I would also like to take a few seconds to address each comment in the oppose notification.

    "There is no problem to solve." A current case at ArbCom says otherwise

    "Whether day or month comes first (3 January; January 3) is trivial—all English-speakers recognize both; the US military uses DMY, as do many Canadians; by contrast, many publications outside North America, including newspapers, use MDY." Recognizing that there are different formats is nothing special. The problem is that each use different standards than each other ans Wikipedia is a conglomeration of all these national preferences.

    "Given this mixed environment, it is unlikely that readers even notice, let alone care, which format is used in an article. Featured articles—which represent our peak standards of professionalism—abandoned autoformatting last September and now exclusively use simple, fixed-text dates; this has barely rated a mention at featured article candidates." While few care which format is used, a quality encyclopedia (which is a goal of Wikipedia) uses consistent dates. Readers do, and should notice these kinds of problems: "The air around Los Angeles was smoggy from 21 December 2008 to January 3, 2009", so people do notice such inconsistencies. Featured Articles' criteria are based upon

    WP:MoS

    for these matters, so they aren't the appropriate venue for such discussions anyway. As a contributor to more than a dozen FAs, I can assure you that formatting hundreds of dates across an article (which primarily occur in references) is a ROYAL pain in the butt!!! and isn't a "simple" thing to do, but date consistency is a requirement for FAs. This would simplify the process dramatically

    "More broadly, one user has unlinked and corrected dates in more than 7,000 articles, yet has received only a handful of objections." Another has done so for far more articles than that and now his actions have placed him at ArbCom.

    "Fundamental principle that there should not be two classes of users. Because some registered editors would see different dates formats from everyone else (see Wikipedia:DONOTLINKDATES), it would inevitably lead to an inconsistent mess of date formats." Entire argument is a red herring. There are already significant differences between registered users and anonymous (namely image uploads, page move, semi-protected pages, etc). Adding one more isn't a big deal. As long as we choose a default date format, there should be no inconsistency with non-registered users.

    "Complex and laborious. Tagging tens of millions of dates with a marker such as {{#formatdate|March 11, 2009}} (double the number of keystrokes—even more if |dmy/md is added), and specially tagging nearly three million articles to establish a default date format, would be an enormous price to pay for the very minor benefit of viewing dates in a specific format, and would complicate matters for new and casual editors. MOSNUM already has simple, well-accepted rules for date formatting, which require no markup. In the context of attempting to achieve a simple solution, WikiMedia's Chief Technical Officer, Brion Vibber, has stated: "My personal recommendation would be to remove all date autoformatting …"." This isn't too complex and a bot could implement it without much trouble and would prevent further problems. The Chief Technical Officer Brion Vibber's opinions are his own and this is less a technical issue than a writing consistency issue. Every writing guide has a standard and every major encyclopedia uses a set date. Why should we be any different?

    "Metadata fallacy..." All seems to be concerned with the linking ability of the text which used to be the norm. This is not the case here and is completely off topic

    "The failure of the original autoformatting was largely due to the ad hoc imposition of a design by programmers acting without agreed specifications (clear objectives) by the community. The so-called fixes suggested are of limited scope and functionality, and have not been agreed to by the community. We should not risk allowing solutions to be tacked on bit by bit over the next few years, requiring increasingly complicated syntax even further remote from the average editor. Among these issues would be non-breaking spaces, AD/BC, slashed, ISO and Gregorian/Julian dates. Date ranges—avoiding the clunkiness and forced repetitions that the original system involved—would be a significant challenge." Okay...so what? We already have these problems, but by standardizing dates, we allow such mass changes Wikipedia-wide to be implemented with a single change to a single template instead of millions of changes.

    — BQZip01 — ^talk 05:39, 1 April 2009 (UTC)[reply]

93. Support - I liked the ability to have the date fit your personal preference before it was depreciated, and set up all the content I wrote as such; plus, of course, what's the point in having the preference option to change it if the articles themselves can't be changed by it?
    talk) 07:25, 1 April 2009 (UTC)[reply
    ]
94. Support - This is a no-brainer. Of course readers should generally see dates in their favorite format. --guyzero | talk 07:30, 1 April 2009 (UTC)[reply]
95. It beats trying to decipher what is really meant by 01-02-03 or 04-05-2006 or 2009-08-07. — Twas Now ( talk • contribs • e-mail ) 09:20, 1 April 2009 (UTC)[reply]
96. Support I think it's a really good idea especially because some people need this sort of ease of use. XxReikoxX - The Visual Asia Geek (talk) 09:38, 1 April 2009 (UTC)[reply]
97. Support – This is really about two different things: should there be some kind of markup to identify something as a date, and should the markup be used to allow personal preferences in formatting. On general principes, markup is usually a good idea, even if we can't think of good uses for it right now. I enjoy having the ability to specify a personal preference for date formatting, and would like the ability to specify personal preferences for even more things in the future (metric versus non metric units, "colour" versus "color", etc.); such things are impossible without markup. I agree with the objection that anonymous users should not be excluded from features enjoyed by logged-in users, and counter that it is possible, in principle, to modify the software to allow anonymous users to store preferences in cookies. I agree with the objection that {{#formatdate|March 11, 2009}} would be complex and laborious, but counter that the actual markup syntax has not yet been determined, and I would hope that it will not be so complex and laborious. I disagree with the objection under "Metadata fallacy" in the "Statement against"; it is almost impossible for a search tool to tell the difference between a date that is a candidate for reformatting and one that is not (for example, dates in quotations should not be reformatted). I agree with the concerns under "Development risks" in the "Statement against", and hope that those concerns are considered when the syntax details are worked out. People who complain about overlinking are missing the point; formatting and linking are independent concepts, even though both require markup. —AlanBarrett (talk) 15:44, 1 April 2009 (UTC)[reply]
98. Support per AlanBarrett, who summarised it really well. —Nightstallion 16:26, 1 April 2009 (UTC)[reply]
99. Support By allowing autoformatting we explicitly mark the fact that a particular piece of date is a date. Any semantic markup of that form gets my support, irrespective of how it is used (within reason). I agree with some of the other comments that the {{#formatdate}} syntax is verbose; perhaps something better can be found. But that's incidental. Writing a bot to convert between syntaxes is easy, as is writing a bot to remove the syntax. (Writing a bot to add markup is necessarily error-prone which means it will annoy people, but hopefully we don't need to do that. A bot that reviewed Lightbot's past edits and reverted all of the date markup removal edits might help.) What do we gain with this? Autoformatting, in the current sense of allowing logged-in users to fiddle with some well-hidden setting and switching between '1 April' and 'April 1' is just the tip of the iceberg. Perhaps in the future we can use
    RDF/A to tell browsers that it is a date, and browsers of the future may support autoformatting. (In fact, I would be surprised if they didn't.) It'll allow software (e.g. webcrawlers) to extract dates from articles in much the same way that Google Maps does with geographical co-ordinates. In five years time who knows what will be possible, and what people will want Wikipedia to be able to do. But I can be fairly sure that retaining as much semantic markup as possible—i.e. marking dates as dates, names as names, and so on—can only help achieve this. Losing information is almost always a retrograde step. So let's have some sort of date markup even if we decide that with today's Mediawiki software we do not wish to enable autoformatting. —ras52 (talk) 17:23, 1 April 2009 (UTC)[reply
    ]
100. Support, but not because I think autoformatting itself is the biggest problem to be solved, but because I think that dates should be captured in appropriate metadata and microformats. Date linking should be avoided unless relevant, but if those links are removed such that plain prose text is all that remains for date markup, then too much valuable information is lost. — Andrwsc (talk · contribs) 18:31, 1 April 2009 (UTC)[reply]
101. Support, Getting the implementation right is important, but I see very little downside to having more meta data and having format customized content. The objections appear to me to be oriented into 1 KISS arguments and 2 waste of time arguments. The first is, without more, a generalization of the second, and the second seems misguided, particularly given the massive number of edits generated by unlinking in the first place. 3 The impact on the casual user is zero, the impact on the power user is relevant only if one chooses to override the settings, and the only downside is on the users that choose to "waste" their time, and the developers that already "wasted" their time programing it (according to the proposal the function already exists). 4 The remaining complaints appear to be based on a misunderstanding (that autoformating = autolinking, a point others make clear is not the proposal), or that 5 everyone should "get over it" or that it's a good educational experience. This last argument barely deserves mention, other than to say that users should be treated as adults (as they are in most other areas of the -pedia) and can educate themselves as to date formats if they choose; paternalistic editors do not need to make that choice for them. Shadowjams (talk) 19:47, 1 April 2009 (UTC)[reply]
102. Support. I prefer to view dates a certain way. Powers ^T 23:41, 1 April 2009 (UTC)[reply]
103. Support. It's a benefit for readers, and the maintenance can be mostly done by bots.
     talk) 00:23, 2 April 2009 (UTC)[reply
     ]
104. Support. I prefer unified date formats, and the meta data may be useful too. Mark Hurd (talk) 02:37, 2 April 2009 (UTC)[reply]
105. Support, I find it easier to edit and read articles not worrying about whether the date is in MDY or DMY, and having the option to choose is a good idea in my opinion, and even if the option is there that doesn't necessarily mean it always has to be formatted correctly, wikipedia is about users editing, so if a user comes across a misformatted date they can change it, if the user doesn't care they don't have to, everybody wins.-- GoldMan60 ¤ Talk  04:39, 2 April 2009 (UTC)[reply]
106. Support It was a great solution for an edit war that I participated in six years ago, and anything that makes it difficult for some to impose their POV about dates is worth having. Eclecticology (talk) 08:25, 2 April 2009 (UTC)[reply]
107. Support Allowing autoformatting by personal preference will stop the whole linking-delinking edit war, allow user's their own preference without forcing it on anyone else. It solves a whole bunch of problems in one go. If the developers were to simply create autoformatting for dates, we wouldn't be having this discussion to begin with. The limited amounts of date formats mean it could even be done without additional formatting if the developers made the effort. - Mgm|^(talk) 09:52, 2 April 2009 (UTC)[reply]
108. Support What with Wikipedia being an encyclopedia, consistency is essential. If a user really objects to having to pay extra attention to the way they input dates, then I'm sure the job could be carried out by a bot, and by supporting users. -m-i-k-e-y-^talk 10:53, 2 April 2009 (UTC)[reply]
109. Weak support "Weak" because of the problem of inconsistency for unregistered users. Ed Fitzgerald _{t / c} 13:08, 2 April 2009 (UTC)[reply]
110. Support, per Jeff (consistent dates, less edit warring).--Esprit15d • talk • contribs 13:29, 2 April 2009 (UTC)[reply]
111. Support, let's concentrate on the contents. leave the formatting to the system. --NullSpace (talk) 14:59, 2 April 2009 (UTC)[reply]
112. Strong Support Personally, I think it IS worth a tad bit of extra effort to have date formatting. However, those who don't want to make the effort can simply leave it to someone else. Should be a no brainer - let those who want formatting have it; let those who do not ignore it. --ThaddeusB (talk) 16:23, 2 April 2009 (UTC)[reply]
113. Support, primarily because it will reduce that pointless and annoying edit warring. Davidelit (talk) 17:13, 2 April 2009 (UTC)[reply]
114. Strong Support Why are people afraid of technology? If you don't like it, turn it off in your preferences, but don't remove options. This was one of the benefits of registering and something that encouraged me to do so originally.--Patrick «» 17:14, 2 April 2009 (UTC)[reply]
115. Support, only because of the metadata argument. If we unmark dates, we're losing information. Recovering that information, by doing regexp searches or whatever, may be frequently possible, but why give ourselves the hassle? --Northernhenge (talk) 17:48, 2 April 2009 (UTC)[reply]
116. I strongly support autoformatting of dates for the simple reason that it is the simplest method for keeping Wikimedia on the side of the READER when it comes to the subject of WYSIWYG that requires the second smallest number of digits. The format that would reduce the number of digits in date formatting to a simple Seven Digit code is one that would use a 4 Digit year, followed by a 3 Digit day, within Brackets, but without interior dashes. This method would rely on the Server interpreting the code, and producing the format dictated by the READER. This method would require calculating the number of the day in question, remembering that there are 366 Days in Leap Years. Granting that this method might be daunting to some, I fall back to the current method, which makes use of a 4 Digit Year, a 2 Digit Month, and a 2 Digit Day, plus 2 interior dashes, to bring up the total number of digits to 10 plus the Brackets. It is the compromise that makes the most sense from all points of view. The Metadata issue is correct as well. As for the issue of Unregistered Users, the simple solution for them is to edit their entry to correct the data format.-SSG Cornelius Seon (Retired) (talk) 17:53, 2 April 2009 (UTC)[reply]
117. Support. Dates are not text. Leaving it to heuristics (or humans!) to figure out what date was "meant" is a Bad Thing. --Alvestrand (talk) 18:42, 2 April 2009 (UTC)[reply]
118. Support, I think we should try to be more inclusive of a variety of date formats. Also, this makes it easy to switch between, for example, linked dates or unlinked dates. A lot of the changes could be made with AutoWikiBrowser / bots.
     u|c 19:43, 2 April 2009 (UTC)[reply
     ]
119. Support. I see no reason to prevent others from getting a format they can read easily, since it doesn't inconvenience people like me who don't care what format they get. An article writer will need to type a few more keystrokes, but will be entering a standard format and won't need to think about choosing a format appropriate to the article subject. As a side issue, I think autoformatting would be a useful social tool to discourage the appearance of confusing numeric dates (3/2/09 vs 2/3/09, etc). Esobocinski (talk) 20:05, 2 April 2009 (UTC)[reply]
120. Support. I think this is a handy feature for users that are not used to the (mostly used) North Amarican date style. Allowing the autoformatting would be a convenient solution for everyone (those who don't care could still be shown the 'normal' date as written in the different articles, whereas those who care could choose their respective preferences). I think this is more the 'wikipedian' way of acting than imposing the date format an author has choosen to use in his article. Old Death (talk) 21:29, 2 April 2009 (UTC)[reply]
121. Support - "This is a no-brainer. Of course readers should generally see dates in their favorite format."
     talk) 21:51, 2 April 2009 (UTC)[reply
     ]
122. Support - Far too many articles are already marked with the globalize maintenance template for the most trivial of reasons, some even more trivial than the formatting of the date. The solution offered to replace autoformatting-- to wit, relying on the "overall format" of an article for date format localisation/localization-- likely will aggravate rather than mitigate this situation. -- JeffBillman (talk) 23:11, 2 April 2009 (UTC)[reply]
123. Support – I'm a fan of options, but I'm an even bigger fan of consistency, which is extremely difficult (more like impossible) to acheive on a wiki site. momoricks (make my day) 00:39, 3 April 2009 (UTC)[reply]
124. Support - Was going to vote "No" on the basis of the difficulty of implementing the Autoformatting system - but on thinking it over I feel that Wikipedia is just the platform for these technological systems to be worked out - and having consistency over all articles for users is a very good thing. In response to the "There's no problem" argument - I don't think that change should necessarily be negated on the basis of having a problem or not. The "If it ain't broke, don't fix it" argument ignores the possibility of new tools that may or may not provide a better experience. You'll never know if you don't try though.
     talk) 02:03, 3 April 2009 (UTC)[reply
     ]
125. Strongly Support Allowing dates to be autoformatted on a per user is an excellent idea. This embodies Wikipedia's spirit of neutrality. The auto format tag adds the benefit of ensuring dates through out Wikipedia are tagged, so if a better format is later discussed, they will can be rolled over to the new format very easily. That being said, I think an easier syntax might make it more understandable to new users.

     I understand that certain people have emotional "buy in" to the current format, spending thousands of man-hours manually editing dates to their current format. For their contribution I thank them, but I have the same appreciation for their thousands of hours of work as I do for a coder who completed a task of similar scale in several hours of coding. (provided that coder didn't step on to many toes.) We must not forget that it is the fruit of your labor that are propagated to the community, not your journey.Gsonnenf (talk) 04:39, 3 April 2009 (UTC)[reply]

126. Conditional Support — Dates should be formatted automatically by the server as the page is assembled for the viewer. Editors shouldn't have to do anything to accomplish this—just type the date consistently throughout an article and it's done. Binksternet (talk) 05:52, 3 April 2009 (UTC)[reply]
127. Support looking to the future, auto-formatting simple-syntax dates provides future proofing beyond what many users currently comprehend. All (well, mostly) BOT achievable and provides a consistency not being achieved currently due largely to inconsistencies and constant edit and reverts. Default presentation for IP users, and even that can be targeted based on perceived location. Preferences can even be provided on individual basis for IP by cookie system such as used by google and countless others. What is the resistance to improvement here? not any work for anyone who doesn't want to do it, BOTs and wikignomes can make it happen far better that current mess. Autoformat also allows instant switchback between linking and unlinking per the annual argument over that - and yes, I am aware linking is not intertwined with formatting.--ClubOranje^T 07:29, 3 April 2009 (UTC)[reply]
128. Support. To me the advantages of autoformatting are obvious. Updating existing pages will gladly be taken care of by bots. Dampinograaf (talk) 21:03, 3 April 2009 (UTC)[reply]
129. Support. --IanOsgood (talk) 22:39, 3 April 2009 (UTC)[reply]
130. Support. Semantic through syntax is a good thing. Plus, a lot of people browse en.wikipedia.org who - IMHO - would like the ISO-style more. Also being able to give more detail for a date and showing only a little (like wikilinks) would result in more readable and still information-packed articles. PAStheLoD (talk) 23:09, 3 April 2009 (UTC)[reply]
131. Support. The days of inflexible mainframe systems are over, for better or worse—and the perceived complexity it allows is probably worse. It is now routine to experience banner advertising which relates to our recent individual browsing history, and websites which greet us by name and remember our preferences, even though they serve millions of users. Adding functionality which obeys a browser cookie to show dates in the preferred format while not reformatting quoted dates is not technically challenging. As wiki functionality goes, it's downright mundane engineering. Besides user friendliness, a big advantage in such encoding is to simplify and promote date harvesting, which could be used to create an event database to answer questions like "Which month has the most shipwrecks in the North Pacific?" "What all happened in Harney County, Oregon in 1894?" "What was the subsequent noteworthy event to happen after Abraham Lincoln died?" —EncMstr (talk) 05:55, 4 April 2009 (UTC)[reply]
132. Support, with some caveats: (a) An unregistered reader must see a consistently formatted set of dates within any one article, by whatever means is possible (tag each article automatically for US/UK variety of English, and make a random assignment where there are no bot-discernible clues? Or something based on the user's IP address, by continent? Or... ?). I see the danger that because all we editors have probably set our date preferences, we don't get to see the potential mess that the majority of readers see. (b) (slight side issue) A top priority must be to avoid, and correct, any use of ambiguous dates like 3-4-2009 or 3/4/2009 (yesterday or last month?) (c) Input required from editors must be minimal in keystrokes and easy to remember, and/or a bot must be able to pick up dates for formatting (suggesting that a "don't format" tag for any date mentioned in a quote or title of a work would be helpful). But on balance, given that the two date formats have as much support as honor/honour etc spellings, I support date formatting if the above can be satisfied. PamD (talk) 10:33, 4 April 2009 (UTC)[reply]
133. Support; to me this is a common-sense feature that an online encyclopedia ought to support, and the extra complexity required is not that much - if complexity had been a concern since the beginning WP would never have been created. Time3000 (talk) 10:48, 4 April 2009 (UTC)[reply]
134. Support; I prefer the idea of uniformity. tsjackso (talk) 14:52, 4 April 2009 (UTC)[reply]
135. Support; If an argument can be found then an argument will occur. You cannot keep everyone happy unless you give them what they prefer. Trivial though it may be arguments have happened over less. If autoformatting can give people their own preferred date format then it's all to the good. The current system works and is only being deprecated by editors looking to find something wrong and then argue about it. Human nature at its very best. So, in my view, autoformatting is the way to go using the current system which is easy to achieve, easy to remember how to do it without any arcane template formatting to remember. Easy is good, easy is less prone to error and best of all easy is a great way of pissing off people who just want to make life difficult just for the sake of it! --WebHamster 15:56, 4 April 2009 (UTC)[reply]
136. Support; Both globalization and localization are made easier this way. There is genuine ambiguity in DMY or YMD e.g. my birthday 12/04/72. Within articles with much collaboration, especially in the references, dates typically ARE NOT consistent within the article even now. Let the machine do the stupid work. Also, just because the facility is there does not mean it has to be made compulsory, any more than linking or putting something into sections is compulsory. SimonTrew (talk) 19:56, 4 April 2009 (UTC)[reply]
137. Support on todays date of 05/02/09 or 02/05/09. Mainly because all English-speakers recognize both is patently false, if this were the case there wouldn't be half the MOS date issues and date revert wars. ^Khukri 23:32, 4 April 2009 (UTC)[reply]
138. Support. It would be nice to have this facility available. If you don't like it, then just don't use it. --catslash (talk) 23:43, 4 April 2009 (UTC)[reply]
139. Support. Consistency, especially within an article, would be a big boon to readability and lessen the vexing task of making sure your dates are internally consistent with the remainder of the existing article. The inconsistency of date formatting across multiple articles is a nuisance for sure, though not a show-stopper. Worrying about all of the existing dates within articles is a red-herring -- there's no requirement to go out and fix them all, though I suspect a robot could be written that would do that. -- btphelps ^{(talk) (contribs)} 01:17, 5 April 2009 (UTC)[reply]
140. Support. It makes sense to be able to identify dates as such without having to link them, and the ability to alter formats on a per-user basis is a bonus. Igenlode (talk) 02:17, 5 April 2009 (UTC)[reply]
141. Support. a) Autoformating should be available as a funtionality separate to and independent from date linking. b) Maybe "all English-speakers recognize both" when it is unambiguous, but "recognising both" is neither the issue nor the problem. The problem is the ambiguity. c) Let the machine do the work. d) If it is available, use is optional (not obligatory). If it is not available ... e) Make it as simple as possible. f) etc. Pdfpdf (talk) 06:52, 5 April 2009 (UTC)[reply]
142. Support Per above, i find it easier and faster to view the dates in a format I am use to Brian | (Talk) 08:01, 5 April 2009 (UTC)[reply]
143. Support markup for metadata purposes, and we might as well have autoformatting for readers who have specifically asked for it. The syntax {{date|...}} would not be that difficult to understand, and you could find documentation at Template:Date. In articles, special syntax using hashes or square brackets would be more of a mystery. JonH (talk) 09:01, 5 April 2009 (UTC)[reply]
144. Support. Most definitely support it in principle and the newer methods for date format is well on its way.
     247 21:11, 5 April 2009 (UTC)[reply
     ]
145. Support Provides user choice and consistency.--Boson (talk) 21:32, 5 April 2009 (UTC)[reply]
146. Support Gives a consistency to the entire wiki. Hohohob (talk) 00:02, 6 April 2009 (UTC)[reply]
147. Support #90 makes compelling points Captndelta (talk) 00:57, 6 April 2009 (UTC)[reply]
148. Support Would automatically solve one of the discrepancies between different types of English for articles - simply choose the format you prefer and Wikipedia displays it automatically. I love this idea and think it has the potential to be expanded into other areas of English too.
     talk) 06:19, 6 April 2009 (UTC)[reply
     ]
149. Support There are two separate issues here. How does the date look to the reader is one, and how is the date actually formatted in the article is the other. As long as there is consistency in the way a date is actually formatted, the problem of how the date looks to the reader is easy to implement. I am all in favor of giving the reader extra options if the cost is low.
     talk) 09:31, 6 April 2009 (UTC)[reply
     ]
150. Support -- It always annoys me that the ~~~~ syntax doesn't autoformat, as it makes it harder to keep the dates and times visually in sync with the history. That's why I always used UTC and yyyy-mm-dd format in my preferences. --William Allen Simpson (talk) 14:17, 6 April 2009 (UTC)[reply]
151. Weak Support -- I support the concept of date auto-formatting for the sole reason of its "enhanced ability to present a consistent date format" in articles.
     
     1. . My support would be strengthened if the addition of this capability were coupled with a change to MOSNUM that required the use of a function (e.g., {{#formatdate}) to format dates
        
     2. My support was not influenced by these arguments:
        1. (in favor) ...benefits are obvious. This is just a summary of the three points in favor; moreover, I found the concept to be worthy of thought before deciding, so was not obvious to me
        2. (against) "There is no problem to solve". While I agree that the problem listed in this argument, "Whether day or month comes first (3 January; January 3)", is unimportant, I do not agree that there are no problems to solve. To the contrary, I believe that the lack of encyclopedic consistency is an issue, and that the lack of consistency of date formatting across the encyclopedia is one part of the overall consistency problem
        3. (against) ...two classes of users. I believe this concern, as described, is not an issue because an individual user, during any given session of being logged in or not, would see a consistent date style
        4. (against) Metadata fallacy. I do not see this argument put forward in the statements in favor of the concept, although it is referenced in some of the comments by those voting
        5. (against) Development risks, only because this argument is a subset of the Complex and laborious argument, with which I do agree, below
     3. My support was weakened by these arguments:
        1. (in favor) ...give users more options. In my opinion, less options in terms of data formatting and more consistency in date style across articles (i.e., throughout the encyclopedia) is a necessary addition to merely adding the (as I understand it, to be specified) functionality. To add the functionality without a change to MOSNUM would change by weak support to oppose
        2. (against) Complex and laborious. I was most influenced in this regard by the referenced statement from the WikiMedia CTO
           --
           talk) 18:38, 6 April 2009 (UTC)[reply
           ]
152. Support Allow users their localised choice. I want to read Wikipedia in as close a style as possible to my native English, and to reduce as far as possible jarring intrusions of US style and practice. Cyclopaedic (talk) 19:29, 6 April 2009 (UTC)[reply]
153. (in favour) This is an important aspect for interoperability in the future. Crossbottle (talk) 22:48, 6 April 2009 (UTC)[reply]
154. Support. Both consistency and user choice are important. There is no technical reason why date-format preferences and other userprefs of a similar nature need to be restricted to registered users; a simple JS hack could allow even unregistered users to choose their preferred date format by setting a session cookie. 121a0012 (talk) 02:58, 7 April 2009 (UTC)[reply]
155. Support. Auto-formatting would help to remove the consistency issues that plague a lot of current articles. It would also be nice to allow users to format as they prefer for convenience.
     talk) 03:35, 7 April 2009 (UTC)[reply
     ]
156. Support It allows the reader to determine how they would like their dates to look and makes sure they're not confused by other styles. AND since everyone gets to pick their own style, it should reduce edit warring over dates in articles. --Falcorian ^(talk) 05:50, 7 April 2009 (UTC)[reply]
157. Support Adds consistency by virtue of all users seeing their preferred format. Any initial pain caused by implementation will be hugely soothed by the long term benefits it would bring. Scrxisi (talk) 12:31, 7 April 2009 (UTC)[reply]
158. Support Definite improvement in general user experience, and this doesn't even need a JS or MediaWiki hack to implement (though they might make it smoother). A template, some CSS classes and the already existing #time parser function would be sufficient to do this. Carolina wren (talk) 16:38, 7 April 2009 (UTC)[reply]
159. Support Wikipedia is a rich Web application. Having an option for user defined date formatting in a rich Web application is a no-brainer. dissolve^talk 19:48, 7 April 2009 (UTC)[reply]
160. Support per #149 and #90. (Yes, I did my own thinking, but other people are better at writing arguments than I am.) ~
     how am I typing? 20:06, 7 April 2009 (UTC)[reply
     ]
161. Support - I don't care greatly about this debate, but I don't have any problem with the general concept of autoformatting. The benefits seem pretty obvious, the costs much less so. Robofish (talk) 23:47, 7 April 2009 (UTC)[reply]
162. Support. Autoformatting is an effective way to localize dates in a format the user is most familiar with, and would prevent inconsistency in date formats across articles. NTP (talk) 04:23, 8 April 2009 (UTC)[reply]
163. Support. There is too much inconsistency in Wikipedia. I support any measure that increases consistency across articles. ...
     talk 08:09, 8 April 2009 (UTC)[reply
     ]
164. Support I like to see a consistent format of dates, but as different users have different preferences, some form of autoformatting is required. -- MightyWarrior (talk) 11:44, 8 April 2009 (UTC)[reply]
165. Support because I think it will be easier to have this feature than to agree a common format for dates; and without an agreed common format, articles begin to look messy and inconsistent. Andrew Dalby 12:41, 8 April 2009 (UTC)[reply]
166. Support This should solve all reasonable problems. Hipocrite (talk) 14:06, 8 April 2009 (UTC)[reply]
167. Support. This, apart from allowing each user to choose date formatting, also gives them the choice of linking dates or not. This should please registered viewers, and the real debate should be over autolinking for unregistered users. (I assume that the date format would be chosen based on the country of origin of the user and thus need not be debated.) — Preceding unsigned comment added by Psbsub (talk • contribs)
168. Support. Just so I can get non-North American date formats! Wikipeterproject (talk) 21:18, 8 April 2009 (UTC)[reply]
169. Support; although as an editor I don't really care one way or the other, as a reader it's simply easier and more accessible to see dates consistently presented in the format I'm accustomed to. EyeSerene^talk 09:49, 9 April 2009 (UTC)[reply]
170. Support. The very fact that there are people who prefer non-North American date formats (such as Wikipeterproject) requires me to vote this way. To me anything other than "April 9, 2009" looks weird and ugly. And I am sure that many Americans see it the same way. Yet I think we have no call for dominating things -- so autoformatting should allow me to see "April 9, 2009" while these others would see "9 April 2009" or "2009-04-09." Why anyone opposes it escapes me. -- BRG (talk) 13:45, 9 April 2009 (UTC)[reply]
171. Support. Though I'm relatively new to Wikipedia (having left the place in 2006 for reasons mostly irrelevant to the discussion here before rejoining recently), I think I need to have a say in this. That stated, and having read both the statements for and against, I think the for statements do make more sense. Firstly, I disagree that we are trying to solve a non-existent problem here. Formatting consistency is an important and integral part of every publication, and the use of inconsistent formatting and double standards reflects unprofessionalism. Yes, it's slightly unfair that unregistered users won't be able to choose the date format they want to use, but this is countered by the fact that they will at least be able to see consistent date formatting on every article. Labourious and complex? I thought this was what bots are for! And the Wikipedia-constrained Google search is underused for a good reason - it's kludge. Why can't we be able to use our own search engine, instead of having to rely on an external search engine? Developmental risks is a real issue, but I believe that, unless we lack the forsight to fix these problems before implementing this solution, this shouldn't be too much of a problem. --A.K.R. (talk) 16:14, 9 April 2009 (UTC)[reply]
172. Support. Many people have different date formats, so {{#formatdate}} can really help. Aside from that, since the poll below (on the page Wikipedia:Date formatting and linking poll) has a majority agreeing that only neccesary dates are linked, if we don't pass this, the dates won't be automatically formatted. So I support the passing of this autoformatting!
     Sign here! 18:52, 9 April 2009 (UTC)[reply
     ]
173. Support - worthwhile standardisation, while retaining person choice. Finavon (talk) 18:55, 9 April 2009 (UTC)[reply]
174. Support Streamlined date formatting across the board would be a big improvement.Drunauthorized 22:46, 9 April 2009 (UTC)
175. Support The uniformity of the dates throughout Wikipedia would be a small, but necessary, improvement to the professionalism of the website Sean118 (talk) 00:03, 10 April 2009 (UTC)[reply]
176. Support Autoformatting prevents edit wars between tiny minds. There are users who think the current link-formatted dates are God's own gift and removing all autoformatting will likely annoy them greatly. Cstaffa (talk) 00:06, 10 April 2009 (UTC)[reply]
177. Support - The option to choose how dates are displayed is an important one- sure, users of both systems can recognize the other, but why should they have to do so? It makes it easier all 'round and prevents edit wars. --Alinnisawest,^{Dalek Empress} (extermination requests here) 03:05, 10 April 2009 (UTC)[reply]
178. Support --Michael (talk) 04:21, 10 April 2009 (UTC)[reply]
179. Support - Having dates in different formats is confusing. --Pot (talk) 04:45, 10 April 2009 (UTC)[reply]
180. Support - Confusion in date formats is rampant in the real world. Let's not make it worse.
     talk) 05:03, 10 April 2009 (UTC)[reply
     ]
181. Support. For readers Wikipedia looks amateurish with the current inconsistency on date formats across—and often even within—articles. Especially the "raw" ISO dates ("2008-05-12") that I observe for the last few months in references using the
     featured list!). In my eyes, date autoformatting is the only way out of this limbo. For IP readers I am convinced that a technical solution can be found that displays "January 14, 2006" for IP's in North America and "14 January 2006" for IP's elsewhere. For editors, the system has to be simple to use and easy to figure out for newbies by looking at existing examples. My preference would be a simple template system based on the ISO standard, for example {{date:2006-01-14}} for above date, {{date:2006-01}} for January 2006, or simply {{date:2006}} for 2006. Intervals could be {{date:2006-01-14/2006-01-22}} for 14–22 January 2006. Etc. if this system can work for others (and it can, otherwise it wouldn't be ISO), it can also work for us! – IbLeo (talk) 05:09, 10 April 2009 (UTC)[reply
     ]
182. Support - Consistency is valuable. This will (eventually) help. Ingolfson (talk) 09:44, 10 April 2009 (UTC)[reply]
183. Support - the most important thing is that the date is easily understood by the reader and that it be consistent across all articles. Formatting to the user's local seems like the right decision here. The linking and delinking of dates has been silly anyway. Many proponents of linked dates were just looking for some consistency in how dates are expressed. Linking to a list of things that happened on that date never provided much value. Effort involved in making this work is not insignificant but this seems like a job ideally suited for a BOT.--RadioFan (talk) 12:05, 10 April 2009 (UTC)[reply]
184. Support - Wikipedia should be genuinely international. If any country other than the US had adoped a different date format we wouldn't even be having this debate. Given the preponderance of US editors, however, it's not unreasonable to toss them a bone and let them format dates as they see fit while the rest of the world gets on with it. AngoraFish 木 13:54, 10 April 2009 (UTC)[reply]
185. Support if the syntax is simple; also, consider something (e.g. teensy superscript dot) to reassure reader he's seeing an autoformatted date and not just literal text that might mislead. But my support vanishes if it in any way leads back to that awful overlinking of years, dates, etc.EEng (talk) 19:03, 10 April 2009 (UTC)[reply]
186. Support Irrelevant links just distract form those that are truly of value to the reader. --droll [chat] 22:38, 10 April 2009 (UTC)[reply]
187. Support The overhead seems minor, and it lets readers see dates in a consistent manner. Also, consider that the day may come when the format "March 11, 2009" looks terribly out of style and we'll all want those individual instances updated. Better to just automate it now, while Wikipedia is still small. Spiel496 (talk) 01:29, 11 April 2009 (UTC)[reply]
188. Support This will improve consistency and display dates per user preferences. But will it eliminate thousands of punctuation errors such as omitting the final comma from "September 9, 1974," where "1974" is essentially an
     talk) 06:29, 11 April 2009 (UTC)[reply
     ]
189. Support to make things easier/more consistent for readers. --Auntof6 (talk) 07:08, 11 April 2009 (UTC)[reply]
190. Support per user Ckatz and the argument about metadata (the most important as I see it). It should also be mandatory using ISO 8601 (proleptic) gregorian dates as input parameter to the #formatdate since this is the International standard nearly every country has adopted (even the US and EU). Nsaa (talk) 10:27, 11 April 2009 (UTC)[reply]
191. Support as date and time are common to all subject areas, and standardization is a logical extension of this. --Gavin Collins (talk|contribs) 10:43, 11 April 2009 (UTC)[reply]
192. Support. Why allow an editor to set a "date and preference" in the their profile, and then ignore it? MeegsC | Talk 11:58, 11 April 2009 (UTC)[reply]
193. Support. The day someone decided that date should be delinked is the day someone created a huge headache for WPTC. We still can't decide because our articles cover the oceans, not land. Potapych (talk) 12:34, 11 April 2009 (UTC)[reply]
194. Support, allows personal choice with minimal issues. (No, "I can't read the wikitext" is not a valid complaint, as it is already unreadable thanks to the pervasiveness of citation templates and parser functions.)
     cool stuff) 18:19, 11 April 2009 (UTC)[reply
     ]
195. Support As a reader, I like it.--Fabrictramp | talk to me 23:17, 11 April 2009 (UTC)[reply]
196. Strong Support. Per IbLeo (#182)--EMU CPA (talk) 02:21, 12 April 2009 (UTC)[reply]
197. Support as long as it is optional, and we don't have bots going around changing plain text dates to formatted dates. Let true consensus, through normal human editing, decide if this is generally useful or not. DHowell (talk) 04:11, 12 April 2009 (UTC)[reply]
198. Support useful feature for improving international usability JulesH (talk) 11:02, 12 April 2009 (UTC)[reply]
199. Support It could be done gradually and optionally (like { { i p a | } } ), and would help solve the other two problems mentioned.—Jchthys 14:34, 12 April 2009 (UTC)[reply]
200. Support No need for any bot runs, but as said above let this develop naturally. The option is important as a fly-by editor one does not want to worry about formatting dates the right way (Is this an American or English article?) Autoformat will do nicelyAgathoclea (talk) 14:38, 12 April 2009 (UTC)[reply]
201. Support - Autoformatting certainly has potential, I would like to see more options - such as users logged out being able to set some kind of preference, to further take advantage of Wikipedia's electronic nature. It is good that linking is no longer required for autoformatting, and the potential is still open to allow bots to do most of the labour, though it could just develop slowly over time through human editing. I do believe consistency across article would be helpful, like with other encyclopaedias, and while it perhaps ought to be trivial this clearly matters to more than a few people.
     (talk) 14:40, 12 April 2009 (UTC)[reply
     ]
202. Strong Support Wikipedia is not a
     WP:PAPER encyclopaedia, and editors who aren't bothered or don't know how to format dates can leave it to editors who can. Symanticising (if that's a word) articles is only a good thing. -- M2Ys4U ^(talk) 15:33, 12 April 2009 (UTC)[reply
     ]
203. Strong Support Makes sense to support the most popular format --Thelostlibertine (talk) 18:01, 12 April 2009 (UTC)[reply]
204. Support. I feel that Linked dates would be good as it would help avoid conflicts as when Tropical cyclones transfer basins it causes headaches for WPTC members. Also i feel that if we are meant to link to "relevent articles" then why shouldnt we link to the date articles? Jason Rees (talk) 23:32, 12 April 2009 (UTC)[reply]
205. Support. Date formatting enables the reader to quickly understand dates, and everyone has their preference (I set mine a while back). For unregistered users, it would be a pipe dream to eventually combine autoformatting with either OS/browser locale settings (if accessable from the web server) or by inferring for the country where the IP address domain orginates (using some kind of GeoIP database). +mt 00:56, 13 April 2009 (UTC)[reply]
206. Support as the best solution to the related article inconsistencies, edit wars and the policy deadlocks that result without it (e.g. the above-mentioned
     WP:NPOV). Also some date formats used in practice (ISO 8601, YMD) are excluded by policy, but could be retrieved with autoformatting. Most of the capability is already implemented in Wikimedia - it's low-hanging fruit in terms of i18n and L10n that should be cleaned up for date ranges and non-registered users, then we should move forward and once again make good use of it. Dl2000 (talk) 01:18, 13 April 2009 (UTC)[reply
     ]
207. Support - I definitely like the idea of having the system (finally) format dates to my own preference, rather than whatever format an author likes. Personally, I prefer "YYYY-MM-DD", since that is what I am used to from computer programming. The other way I like to see dates is "DDDD, MMMM D, YYYY". The thought of being able to change dates around like that (something computers can do so easily) is very nice. I've always hated using wiki markup as a kludge to make that work, so I tended not to do so. But once this gets approved and we can start formatting dates automagically, that will be wonderful. It should be as automatic and transparent to the user as possible. Ideally, no special tags required. If a date is in the article and recognizable as a date, the software should adapt it. If there is something that's not a date but is recognized as one, there should be a simple tag (nowiki perhaps, being familiar and similar in purpose?) that would prevent false positives. --Willscrlt (→“¡¿Talk?!”) 14:06, 13 April 2009 (UTC)[reply]
208. Support Readers who care enough to set a preference for date format should be able to see dates consistently displayed that way. Readers who do not care enough to set a preference just do not care, and the anti-formatting editors should not care about them either; at least those readers would see them in a consistent format that adds to a professional appearance. Chris the speller (talk) 14:10, 13 April 2009 (UTC)[reply]
209. Support. This improves the look and feel of the encyclopedia, by providing the option for (registered) users to view their content in the most appropriate format for their needs. Although unregistered users cannot do this through a preferences setting, it might be possible to implement a localization cookie, or some such thing, that offers them the same option. For the casual unregistered user (of which there are many), by autoformatting, we could define a default state for each article, so that the edit wars could be confined to a localization template that sets default date formatting (and maybe other style conventions) for the entire article. With that, there is still a net benefit to all users in terms of formatting consistency, even though only some users would be aware of the additional benefit of setting their own preferred format. I do acknowledge that there could be a performance penalty due to parsing dates, but having implemented date parsing on other platforms, I can't see this as being a disproportionate disadvantage, computationally. Also, although I'm not familiar with the MediaWiki implementation, it seems reasonably simple to cache these computational results in a way that limits the penalty. Basically, unless the backend of MediaWiki is a mess, I doubt that there will be significant performance losses, compared to the regular loading of pages and evaluation of templates. Finally, any good implementation ought to avoid mandatory linking of the date (which appears to be the intent of the poll question)—but by the same token, the syntax chosen should not prevent date-linking, when appropriate. TheFeds 16:23, 13 April 2009 (UTC)[reply]

I oppose the general concept of autoformatting

1. Oppose If Brion thinks that Autoformatting should be removed, that's good enough for me. I think the benefits of autoformatting do not outweigh the trouble implementing it will cause, such as tagging millions of dates with a marker to allow autoformatting.
   24 23:12, 29 March 2009 (UTC)[reply
   ]
2. Oppose Per all of the arguments against. We don't need more options. Neither of the accepted date styles are difficult to understand. I think we should continue to move away from the ISO style and we shouldn't be relying on autoformatting for consistency. Rambo's Revenge (How am I doing?) 23:16, 29 March 2009 (UTC)[reply]
3. Oppose: This is complicated software, don't let anyone persuade you it's a piece of cake. If they haven't been able to get it right in SIX YEARS, nothing makes me think they will get it right any time soon. Of course Brion Vibber knows what he's talking about. While people say 'no pain, no gain', this is just sooo much pain for little gain. Applying lipstick to a pig doesn't change the fact it's a pig. Ohconfucius (talk) 23:21, 29 March 2009 (UTC)[reply]
4. Weakly oppose. If this issue were to arise now, we would solve it by permitting both formats, along the lines of
   WP:ENGVAR. Autoformatting was a failed effort at a technical fix to a behavioral problem, and it faces irresoluble grammatical difficulties about whether a comma comes after the date. Septentrionalis PMAnderson 23:23, 29 March 2009 (UTC)[reply
   ]
5. Oppose per PMAnderson. --John (talk) 23:34, 29 March 2009 (UTC)[reply]
6. Oppose. The bugzilla analysis is generally against it. Most users can understand both major formats (DMY and MDY). I see no point if it's not going to be retro-fitted, but that's likely to be a nightmare - and automating it would be very risky, as the bugzilla analysis identifies types of cases where automated retro-fitting would be wrong. Finally if making it work requires a template or any other extra mark-up typing, I'm totally against it - WP is so prone to
   WP:CREEP that it would probably become a MOS requirement in a few years, and I know no mechanism by which we could legislate now that MOS should never require it. -Philcha (talk) 23:45, 29 March 2009 (UTC)[reply
   ]
7. Oppose There is no "problem" to solve. As it has been noted,
   WP:ENGVAR works well for English variants, so why not dates? Dabomb87 (talk) 23:47, 29 March 2009 (UTC)[reply
   ]
8. Oppose. -- Donald Albury 23:53, 29 March 2009 (UTC)[reply]
9. Oppose: What problem are we trying to solve by this? seicer | talk | contribs 23:55, 29 March 2009 (UTC)[reply]
10. As a featured contributor, I have found no reason for it. --Der Wohltempierte Fuchs ^(talk) 23:57, 29 March 2009 (UTC)[reply]
11. Oppose. The "pro" arguments are not convincing at all, but the "contra" arguments describe very real problems. All the disadvantages just to give a few people the option to display an article with US spelling in UK date format or vice versa? This is obvious feature bloat. --Hans Adler (talk) 00:00, 30 March 2009 (UTC)[reply]
12. Oppose - Most Wikipedia users are readers, not editors, therefore most features should be designed for them. Datelinking devalues useful links. It also necessitates useless extra work for editors.
    talk) 00:07, 30 March 2009 (UTC)[reply
    ]
13. Oppose autoformatting. I hate that meaningless blue mess of
    overlinked dates. And isn't it rather odd that people from the US and UK are supposed to be befuddled by each other's practically identical date formats, when the rest of the world with their much more wildly variable date formatting is quite capable of understanding both of them? Bishonen | talk 00:07, 30 March 2009 (UTC).[reply
    ]
14. Oppose, I don't really see this as needed, I'm not convinced there's a problem that needs this as a solution. Raven1977^{Talk to me}_{My edits} 00:15, 30 March 2009 (UTC)[reply]
15. Oppose I would have thought this had been settled the first, second, and
    MOSNUM guidelines), write it out in fixed text, and be done with it. Jumping through all these hoops just so a handful of editors can be spared the shock of seeing a date format they disapprove of is something they will survive; I guarantee it. Greg L (talk) 00:26, 30 March 2009 (UTC)[reply
    ]
16. Oppose. If Wikipedia readers are smart enough to handle "colour" vs "color" and "aluminium" vs "aluminum", they can handle "30 March" vs "March 30". On that premise, I would apply the KISS principle and avoid the added complexity. -- Tcncv (talk) 00:31, 30 March 2009 (UTC)[reply]
17. Oppose: there is no need for autoformatting. As already mentioned, it enhances the differences between the registered and unregistered uses, masking any potential inconsistencies. Every article should be consistent, using
    talk) 00:36, 30 March 2009 (UTC)[reply
    ]
18. Per Tcncv. NuclearWarfare _(Talk) 00:46, 30 March 2009 (UTC)[reply]
19. Oppose. Editors seeing a different output than the readers is a recipe for disaster. I appreciate autoformating, it is nice to have (international format FTW), but when I first became aware of its shortcomings, I stopped using it. Ever since, I've seen a great deal of articles being inconsistent because of this. Articles that have been fixed because I turned the feature off. The only way I would support autoformatting is if ALL articles would have the SAME ouput for unregistered users, preferably international dates (DD MM YYYY) as we are addressing an international readership. AKA, no tagging individual pages with magic words specifying in what format dates should be displayed, that's just asking for having endless revert wars until the end of time.
    WP Physics} 01:24, 30 March 2009 (UTC)[reply
    ]
20. Oppose: the pros pointed out benefit only those who are logged in. For those who are not logged or are not registered users, they might see dates of varying formats. Autoformat does not promote consistency; the actual text is still inconsistent (and as pointed, obvious to those not logged in). Without autoformat, editors would readily spot any consistency errors in the date formats for an article. Jappalang (talk) 01:46, 30 March 2009 (UTC) Add-on: this is added in response to Sapphic's broadcasting to users who have opposed on the grounds that "autoformatting can be fixed for anonymous users".[1][2] It still does not solve anything, firstly, no one has come up with a workable solution yet (it is only proposed). Secondly, Editors do not need to jump through more hoops to simply input a date. My oppose stands. Jappalang (talk) 01:19, 1 April 2009 (UTC)[reply]
21. Oppose - The readers should see the same thing a logged in editor sees, and we shouldn't have to jump through a million hoops to make that happen. Ealdgyth - Talk 01:47, 30 March 2009 (UTC)[reply]
22. Oppose The autoformat system links a date to an article about that date not necessarily about the specifics that were identified in the original article. I see them also as a blur of blue on an article, which serves only to completely confuse a newcomer trying out each of the wikilinks. As to seeing the format in the date of preference, merely write the article for the audience especially if the article is substantially about a European subject where the day-month-year standard predominates or in military articles. Again, this is a solution looking for a problem to solve. FWiW Bzuk (talk) 01:59, 30 March 2009 (UTC).[reply]
23. Oppose: Marking up millions of articles for the benefit of few editors is definitely not worth the effort .SteveB67 (talk) 02:07, 30 March 2009 (UTC)[reply]
24. –Juliancolton | ^Talk 02:13, 30 March 2009 (UTC)[reply]
25. Oppose: there are so many reasons—the costs are horrendous and the benefit little (frankly, nothing, since day-month/month-day order is trivial); the risks are high that things will go mucky or that we'll be left holding a very smelly puppy; it breaks a basic principle that simplicity is best (if at all possible, and it is the reality now). I hope WPians do the cautious thing and throw this one out for good. Tony (talk) 03:31, 30 March 2009 (UTC)[reply]
26. Oppose: too much monkey business. dates should be entered in a consistent format throughout articles, and logged-in editors should see the same thing unlogged-in readers see.
    Sssoul (talk) 04:21, 30 March 2009 (UTC)[reply
    ]
27. Oppose. This seems like a lower priority than spelling autoformatting ({{#formatword|color|colour}}), and would make the edit boxes just as hard to read.--Srleffler (talk) 04:42, 30 March 2009 (UTC)[reply]
28. Oppose—
    t 05:01, 30 March 2009 (UTC)[reply
    ]
29. Oppose, Pmanderson puts it rather well. Fut.Perf. ☼ 05:58, 30 March 2009 (UTC)[reply]
30. Oppose As the previous arguments pointed out this issue is MoS & behavior related not technical. --KrebMarkt 06:44, 30 March 2009 (UTC)[reply]
31. Oppose The argument against summarizes the point perfectly. This will create a ton of work for a ton of editors for very little gain. Oren0 (talk) 07:12, 30 March 2009 (UTC)[reply]
32. Oppose Extra typing and proofreading for no real benefit. bridies (talk) 07:29, 30 March 2009 (UTC)[reply]
33. Oppose Agree with the arguments against.
    talk) 08:04, 30 March 2009 (UTC)[reply
    ]
34. Oppose. Autoformatting forces mass medication down the throats of healthy people, just because a few people don't like to sneeze. Lightmouse (talk) 08:09, 30 March 2009 (UTC)[reply]
35. Trivial and unnecessary expansion of bandwidth.
    talk) 08:09, 30 March 2009 (UTC)[reply
    ]
36. Oppose Completely unnecessary. The next thing could be "auto-shift-between-US-and-English-English".--HJensen, talk 09:03, 30 March 2009 (UTC)[reply]
37. Oppose Marking up every date in every article (millions of them) - just so that people can choose between day-month and month-day? Madness! Colonies Chris (talk) 09:19, 30 March 2009 (UTC)[reply]
38. Oppose Honestly think this is alot of work for very little gain. dottydotdot (talk) 10:03, 30 March 2009 (UTC)[reply]
39. Oppose. Tcncv (talk · contribs) puts it nicely. — TKD::{talk} 11:04, 30 March 2009 (UTC)[reply]
40. Oppose. For all the same reasons as every other time we've been asked the same question. Utterly pointless function that provides extra work and complication for editors and developers, while providing nothing of value for anyone (especially our readers who won't see it anyway). Will also damage Wikipedia, since if editors use this tool then they won't see dates as readers see them, and so will leave certain errors (punctuation, format consistency) uncorrected.--Kotniski (talk) 11:18, 30 March 2009 (UTC)[reply]
41. Oppose. I do understand the difference between autoformatting and linking. I can see many problems resulting from autoformatting. Anyone who has cursed at MS Word (as I do when using someone else's machine) should oppose an extension of nannydom. (I use OpenOffice.) Peridon (talk) 12:34, 30 March 2009 (UTC)[reply]
42. Oppose. They look silly, often link to completely unrelated pages and devalue important links in "difficult" articles. I have contributed three FAs and I see absolutely no value in having linked dates. When I first discovered Wikipedia, I clicked on those silly linked dates thinking that additional information on the subject in question could be found. I am sure others have done this.
    ^Talk 13:01, 30 March 2009 (UTC)[reply
    ]
43. Oppose it's a "solution" to a "problem" that is not serious, and implementing it would be just add another never-ending task for Wikipedia. (New users won't necessarily know how to autoformat dates, so we would be constantly having to clean up after them.) rʨanaɢ ^talk/_contribs 13:18, 30 March 2009 (UTC)[reply]
44. Oppose given the extra work for minimal benefit. --NE2 13:37, 30 March 2009 (UTC)[reply]
45. Oppose without repeating the reasoning for the gazillionth time in yet another poll (and noting that most of the Support reasoning is faulty). SandyGeorgia (Talk) 13:38, 30 March 2009 (UTC)[reply]
46. Oppose. How many more polls on this issue are we going to take? — Emil J. 13:40, 30 March 2009 (UTC)[reply]
47. Oppose. What matters the most is internal consistency in articles (as in the language question), and autoformatting is not needed for this purpose. Punkmorten (talk) 13:43, 30 March 2009 (UTC)[reply]
48. Oppose. While not having a strong or informed opinion either way, the idea does not stike me as a good one. Adds complexity where none is needed and seems to invent a problem and fix it. JBarta (talk) 13:51, 30 March 2009 (UTC)[reply]
49. Oppose With autoformatting forbidden, editors will see what readers see, and thus do a better job creating content for readers. The typical reader is not logged in and has no preferences. In addition, both options for implementing autoformatting are problematic. Linking creates link cruft that hides value added links for readers. Using templates will make it harder for us to get new editors, as it becomes one more piece of syntax for them to learn in order to make a change that should be simple.
    GRBerry 14:01, 30 March 2009 (UTC)[reply
    ]
50. Oppose I am against anything which further increases the differences between registered and unregistered users - Dumelow (talk) 14:15, 30 March 2009 (UTC)[reply]
51. Oppose There is no need for it. I understand both date formats, and (almost?)everyone else that can read English does too. And it's not exactly hard to figure out if you aren't familiar with one of the date formats. Rreagan007 (talk) 14:49, 30 March 2009 (UTC)[reply]
52. Oppose I have opposed before and i will do it again.--SkyWalker (talk) 14:56, 30 March 2009 (UTC)[reply]
53. weak oppose I do not see how the benefits muster up against the expended resources. Had some type of standard been in place before the content of Wikipedia had burgeoned so, perhaps, but trying to retrofit seems silly.-- The Red Pen of Doom 14:58, 30 March 2009 (UTC)[reply]
54. Oppose The crux of the question is, for whom is Wikipedia intended – the relatively small number of registered editors or the millions of unregistered readers who use it as an online encyclopedia? All of the arguments in favor of auto-formatting dates are irrelevent to the vast majority who read a Wikipedia article without registration. Unlike options such as bold and italic text or section headers, which appear to registered and unregistered alike, special markup does not "enhance the presentation of articles" for unregistered readers, nor does it help achieve "a consistent format across the entire publication" at all. In fact, auto-formatting only benefits registered editors and its removal actually enhances the presentation of articles to the unregistered viewer by eliminating the distraction of annoying and confusing blue date highlighting.  JGHowes  ^talk 15:06, 30 March 2009 (UTC)[reply]
55. Oppose In some fields, e.g. history, the format of a date can be an important element of its information content. To be sure, an opportunity for autoformatting is not the same thing as the automatic use of autoformatting. But an opportunity for the content to be changed by something other than the thoughtful decision of an editor seems intrinsically dangerous to the accuracy and authenticity of encyclopedic information. Maybe it would be different if the autoformatting would work only conditionally, e.g. if a special flag is both entered into some article's wikitext, and actually turned 'on' -- to reflect a conscious decision by an editor that date-formats are not of intrinsic importance in this article. Terry0051 (talk) 15:09, 30 March 2009 (UTC)[reply]
56. Oppose The effort isn't worth it, since, as noted, we really have no problem recognizing and understanding these dates regardless of the format. We need this no more than we need special markup so that words end consistently with -or or -our, or so that they end consistently with -ize or -ise (but in words where the usage varies!), or so that serial commas do or don't appear, or so that primary quotations are delimited by single or double quotations marks, according to our preferences. —Largo Plazo (talk) 15:08, 30 March 2009 (UTC)[reply]
57. Oppose. Who is Wikipedia for, the readers or the editors? The vast majority of our users never edit and are not registered. And from the perspective of an unregistered user, autoformatting makes our articles worse, not better, because it encourages editors to format their dates without regard for the way dates are generally formatted in the article concerned. A simple extension of
    WP:ENGVAR solves the problem. Pfainuk talk 15:22, 30 March 2009 (UTC)[reply
    ]
58. Oppose any type of autoformatting that requires that dates (or pages) have special syntax. This is a barrier to entry for new/inexperienced editors which does not appear to by justified by the negligible benefit it provides to registered users. I would be surprised if there were many editors who did not understand that 2 March and March 2 are the same date. I also oppose automatic autoformatting of all dates on a page because that would negatively impact quotations, which should have the date in the format that it was used in the source. Karanacs (talk) 15:23, 30 March 2009 (UTC)[reply]
59. Oppose Not worth the effort. Alan16 ^talk 15:53, 30 March 2009 (UTC)[reply]
60. Oppose <sigh> Congratulations to Ryan P and all others who've tried to keep this going in a civil manner, but this topic is tiresome. Autoformatting brings no benefits and has downsides. --Dweller (talk) 15:57, 30 March 2009 (UTC)[reply]
61. Oppose --JBC3 (talk) 16:04, 30 March 2009 (UTC)[reply]
62. Oppose Not worth the effort and would reduce the readability of the wiki source. Plastikspork (talk) 16:20, 30 March 2009 (UTC)[reply]
63. Oppose, way too much complexity for most users, and zero benefit for the vast majority of our readers. --Laser brain (talk) 16:21, 30 March 2009 (UTC)[reply]
64. Oppose I honestly don't see the point - dates are more than readable as they are. It's just making extra wok for minimal gain. Whilst I can see the interest on forums, I think Wikipedia should just leave its style be. Greggers ^{(t • c)} 16:23, 30 March 2009 (UTC)[reply]
65. Oppose PMAnderson summarises my views exactly. --RexxS (talk) 16:37, 30 March 2009 (UTC)[reply]
66. Oppose, this seems to be creating more work and problems with very little benefit. We have some amazing programmers who can help us through any perceived problems. Our readers deserve better articles and we really have spent a lot of energy on these discussions and project-wide on this issue.
    -- Banjeboi 16:50, 30 March 2009 (UTC)[reply
    ]
67. Oppose: Others said it well, namely Pfainuk, Greg L, Largo Plazo, and GRBerry. An extension of WP:ENGVAR is applicable to the issue of date formats, and far preferable to encouraging editors to observe only their local formats. We have no trouble recognising the different variations and might as well autoformat serial commas or whatever other myriad of variations are lurking in the English language. I vote for focusing on perfecting content and having internally consistent articles, instead of creating loads of work to allow an editor-only preference which half would never bother "turning on" anyway.
    talk 16:56, 30 March 2009 (UTC)[reply
    ]
68. Oppose Violates KISS principle and also, Autoformatting is an excessive approach for such a minor aspect: All our readers perfectly understand both MD and DM. Have you ever seen a child look at MD/DM dates and say "what does that mean"? Too much of the community's time has been taken up with this already. We all have better things to contribute to/improve Wikipedia. Sillyfolkboy (talk) 17:06, 30 March 2009 (UTC)[reply]
69. Oppose As long as dates are consistent within an article there is no problem c.f. other international variations. OrangeDog (talk • edits) 17:19, 30 March 2009 (UTC)[reply]
70. Unnecessary concession to people who get worked up over nothing.--Scott Mac (Doc) 17:28, 30 March 2009 (UTC)[reply]
71. Oppose autoformatting It seems unimportant and prone to problems. I also oppose further iterations of this issue-that-refuses-to-die. The "losing" editors should start acting like adults and accept the fact that the community consensus is against them. WhatamIdoing (talk) 17:30, 30 March 2009 (UTC)[reply]
72. Edit Conflicted Oppose I'll first point out the all-knowing nature of devs (see link). This understood, I agree with Brion that it doesn't need to be done and that we tend to make things harder than they need to be on WP. I see benefits, but the cons certainly outweigh the pros. hmwithτ 17:33, 30 March 2009 (UTC)[reply]
73. Oppose I think it's difficult to decouple autoformatting from autolinking - currently, you have to make a link or use a parser function. The former is distracting when you view an article, the latter when you edit an article. I don't think the feature is worth the hassle. The resultantly simpler wikitext syntax will benefit new editors and performance, by making the code (slightly) less complex. RupertMillard (Talk) 17:37, 30 March 2009 (UTC)[reply]

    Apparently this was insufficiently clear for User:Sapphic's taste. I don't mean it's technically difficult to have one without the other because that would be absurd. I meant it's difficult to debate one in isolation — if the only way WP will have autoformatting is with [[]] syntax (autolinking or not) or {{#formatdate}}, the resultantly ugly/hackish wikitext is IMO too great a price to pay for a very slight benefit. Now if somebody wants to ask me about autoformatting with new syntax such as <<2009-04-01>>, as I think I saw somewhere, I'll be neutral, as long as IP users see something easy on the eye, be it tailored to their location or not. RupertMillard (Talk) 08:32, 2 April 2009 (UTC)[reply]

74. Oppose per others. TheAE talk/sign 18:44, 30 March 2009 (UTC)[reply]
75. Oppose. Better to embrace the international diversities than use the User prefs to snub them. One should become accustomed to seeing the differences just like you would at your bookshelf. That is part of the learning experience.
    ⋙–Berean–Hunter—► ((⊕)) 18:49, 30 March 2009 (UTC)[reply]
76. Oppose. Autoformatting, even if it could be made to work properly, offers very little advantage but has very significant disadvantages, as others have drawn attention to above. --
    Fatuorum 19:16, 30 March 2009 (UTC)[reply
    ]
77. Oppose. Liffey (talk) 19:24, 30 March 2009 (UTC)[reply]
78. Oppose, solution without a problem. —
    (❝?!❞) 19:32, 30 March 2009 (UTC)[reply
    ]
79. Oppose ... always have and always will 21st CENTURY GREENSTUFF 20:01, 30 March 2009 (UTC)[reply]
80. Oppose. Lots of extra work for everyone for a trivial benefit for a tiny minority. Let's get back to improving the encyclopedia. —Remember the dot ^(talk) 20:09, 30 March 2009 (UTC)[reply]
81. Oppose Alohasoy (talk) 20:10, 30 March 2009 (UTC)[reply]
82. Oppose Minor gains in readability for some people who have issues with date formats cross-articles are not worth the effort to format all dates everywhere in the encyclopedia. Even americans can learn to read DD/MM/YYYY.
    T 20:14, 30 March 2009 (UTC)[reply
    ]

    I'm obviously joking in the above comment; I'm American.

    T 09:25, 1 April 2009 (UTC)[reply

    ]

83. Oppose I can really see no clear reason for doing this; it just isn't that much of a problem. If it applied to everyone, maybe, but just for logged in users... nah. Anaxial (talk) 20:38, 30 March 2009 (UTC)[reply]

    To clarify: the fact that it's possible to have this apply to everyone means I am less strongly opposed than I would be otherwise; but it doesn't change my actual vote, because my first sentence above still stands. Anaxial (talk) 17:32, 1 April 2009 (UTC)[reply]

84. Oppose As long as dates are entered in a consistent format throughout each article, there is no real problem. WP:ENGVAR works well for English variants, dates should be just an extension of this. CS⁴⁶ 21:06, 30 March 2009 (UTC)[reply]
85. Oppose since autoformatting would apply only to the minority of readers who are also registered editors. I would support a technical autoformatting solution that would allow a given format to be applied to an individual article (with exceptions for dates in quotations and the like) for all readers, but that doesn't seem to be what's being discussed here. —Josiah Rowe (talk • contribs) 21:12, 30 March 2009 (UTC)[reply]
86. Oppose Only because of the variations in formatting will not satisfy everyone. As we do with spelling, I believe the US articles should be allowed to maintain the May 9, 1957 format - while the UK, Aussie, and other outside US articles should be allowed to use the 9 May 1957 format. If we can (or will be able to) set our preferences as a default, and this becomes a non-issue, then I would then support. —
    (yes?)/_© 21:18, 30 March 2009 (UTC)[reply
    ]
87. Oppose There is no problem to solve here and this will create more problems - Ahunt (talk) 22:05, 30 March 2009 (UTC)[reply]
88. Oppose I see no reason for it. Aside from unnecessarily complicating things, I can't see what this would accomplish. faithless (^speak) 22:19, 30 March 2009 (UTC)[reply]
89. Oppose. A lot of busy work for no extensive gain. Wildhartlivie (talk) 22:33, 30 March 2009 (UTC)[reply]
90. Oppose - ugh, another RFC? How many times are we going to go through this? --PresN 23:43, 30 March 2009 (UTC)[reply]
91. Oppose. There is no ambiguity in understanding the two formats allowed. A lot of effort for a purely cosmetic issue. Same issue as regional spelling differences and should be treated exactly the same way. --NrDg 00:02, 31 March 2009 (UTC)[reply]
92. Oppose - There's no reason why general readers should see something different than a few logged-in users who have preferences set. Giants2008 (17-14) 00:12, 31 March 2009 (UTC)[reply]
93. Oppose, serves no purpose link wise as the links do not go anywhere useful, adding excessive blue links everywhere (by default, automatically "overlinks" article as dates are usually repeated multiple times. Also negates the purpose of even formatting dates in articles, and can be confusing to IP and new users who see one thing in the article, decide to edit, and see something totally different. Write them as text, and leave it at that. -- Collectonian (talk · contribs) 01:55, 31 March 2009 (UTC)[reply]
94. Oppose. Auto-formatting is a "solution" looking for a problem. It's not even a good solution as it cannot address every date format currently used on WP; and there is no indication that a technical solution can even be found for all the issues raised during the debate. If a technical solution is implemented, its syntax promises to be complex enough to place it beyond the reach of the average editor. A real solution to the date-consistency "problem" is to simply enter dates in a consistent manner—using plain text. All other significant issues simply disappear with the "plain text" strategy.
     HWV258  02:07, 31 March 2009 (UTC)[reply
    ]
95. Oppose. Computer software should be as simple as possible. Once you begin complicating it you always get into trouble. VikSol 02:32, 31 March 2009 (UTC)[reply]
96. Oppose Auto-formatting. No good reason to have to bother with this. Hmains (talk) 03:01, 31 March 2009 (UTC)[reply]
97. Oppose autoformatting. This is a technical solution that lacks a problem to solve. Tempshill (talk) 03:04, 31 March 2009 (UTC)[reply]
98. Oppose: It looks like a solution in search of a problem. There is a significant penalty in terms of making the markup more complicated and intimidating to new users. Keep it simple. Hawthorn (talk) 03:09, 31 March 2009 (UTC)[reply]
99. Oppose. I don't care if my date is formatted one way or the other. It's like color vs colour. I can read and comprehend both. RainbowOfLight ^Talk 03:22, 31 March 2009 (UTC)[reply]
100. "Welcome to Wikipedia, the encyclopedia that anyone can edit." What I have always liked about Wikipedia is that the biggest thing you need to learn to contribute is how to make a wikilink. Basic information like dates shouldn't require formatting more complex than that. Wikipedia has developed a culture that does discourage new users and old alike and there's no need to code the site to be in synch with that exclusionary culture.
     otherlleft^{No, really, other way . . .} 03:33, 31 March 2009 (UTC)[reply
     ]
101. Oppose Autoformatting Date linking served no rational purpose and wasted the time of writers and editors. I don't want it to return. Finetooth (talk) 03:47, 31 March 2009 (UTC)[reply]
102. Oppose so-called autoformatting. It is really unneeded and overly complicated for editing the raw text behind every article. Too much markup intimidates everybody. Well, it intimidates me. Sincerely, a friend to all,
     talk) 05:03, 31 March 2009 (UTC)[reply
     ]
103. Oppose Simply too trivial to be worth the expenditure of any amount of time or keystrokes by editors or developers. Fixed-text dates of any format are equally useful to readers. --Clay Collier (talk) 05:05, 31 March 2009 (UTC)[reply]
104. Oppose Correct me if I'm wrong in assuming the vast majority of users, which means all the readers/editors that never register an account, do not have date formatting turned on. The usefulness is so superficial that it becomes actually not useful considering the small minority that use it. I was very initially opposed to the mass delinking when it first started just because I dislike change like any other human, but I think it's a good idea now after thinking about it for a little bit. LonelyMarble (talk) 06:34, 31 March 2009 (UTC)[reply]
     • For anyone interested, I expanded on my oppose comment on my talk page. LonelyMarble (talk) 21:34, 3 April 2009 (UTC)[reply]
105. Oppose Every little added complexity to wikitext mark-up makes it harder to pretend that this is an encyclopdia anyone can edit. Ian Spackman (talk) 07:18, 31 March 2009 (UTC)[reply]
106. Oppose: There's no problem that this solves. If dates must be in a certain format, they can be treated similar to British vs. American English: a given format should be used where it is reasonable. NJGW (talk) 07:54, 31 March 2009 (UTC)[reply]
107. Weak Oppose: I'd oppose more strongly if I felt it was an important issue, but I don't see that we should be offering autoformatting if it isn't consistent across all dates in the encyclopedia (including sigs), and it could allow for all sorts of dates in the first place. However, it's a bit of a non-issue, we'd do better to agree a recognised style in the MOS if only that was possible. -- WORMMЯOW  08:03, 31 March 2009 (UTC)[reply]
108. Oppose We need less links on pages. Linked dates clog up pages with blue, reducing readability. They also make pages look less professional. We do not have a linked autoformatting system to 'convert' between US/UK spelling, why should we have it for a dating system that is completely mutually understandable? Autoformatting has been a constraint for Wikipedia for years, and should be gotten rid of as soon as possible. Arsenikk ^(talk) 08:07, 31 March 2009 (UTC)[reply]
109. Oppose Autoformatting is not seen by unregistered users, but the datelinks are, and they look like a classic case of
     overlinking. In fact, for years I wasn't even aware of the autoformat feature and was constantly irritated at these superfluous links. They still seem unprofessional to me, just like you wouldn't link the word "born" in "Barack Obama was born in Hawaii." --Zvika (talk) 08:54, 31 March 2009 (UTC) Added in response to a comment by Sapphic: While my main opposition is to datelinks, I also oppose autoformatting which does not appear as a link, primarily because of the wikimarkup complications which appear to be inevitable with this kind of approach. Our markup needs simplification, not the opposite. Perhaps one day, when we have a WYSIWYG editor. --Zvika (talk) 13:36, 1 April 2009 (UTC)[reply
     ]
110. Oppose Can create far too many blue links in articles. --JD554 (talk) 11:35, 31 March 2009 (UTC)[reply]
111. Apart from the issue of overlinking, this is one encyclopedia project producing one version of an article for everybody. What's next, allowing users to switch between American/British English? Even if such customization were desirable, it is certainly not worth the effort and complication.  Sandstein  11:44, 31 March 2009 (UTC)[reply]
112. Yay! Options on date formats is just what I'd like to see distract me from writing articles. No problem to solve, leave it alone. —Cyclonenim (talk · contribs · email) 11:54, 31 March 2009 (UTC)[reply]
113. Oppose The format of the date is an ENGVAR issue like spelling or grammar. An article should be self-consistent wrt all of these. Colin°^Talk 12:33, 31 March 2009 (UTC)[reply]
114. Oppose There is no problem to fix, by attempting to fix something which is perfectly fine, all that will happen is that we will generate more problems, for example, over-linking, development issues, etc Spitfire^Tally-ho! 12:54, 31 March 2009 (UTC)[reply]
115. Oppose --Apoc2400 (talk) 15:00, 31 March 2009 (UTC)[reply]
116. Oppose I was hugely relieved when autoformatting was stopped last summer - For the majority of users, they are excessive and pointless links with very little benefit. Everyone understands what is meant, whether the format used is "Day Month" or "Month Day". As long as we are consistent within individual articles then there is no problem to address.--Jackyd101 (talk) 16:00, 31 March 2009 (UTC)[reply]
117. Oppose. Just because we can do something, doesn't mean we should, or that we need to. The format of a date in an article is not a significant issue.
     Wikipedia:Manual_of_Style_(dates_and_numbers)#Dates covers the situation well enough. People are quite used to seeing 17 November 1956 and November 17, 1956 - and these do not cause a problem. Both versions are understandable by readers, and most people encounter both versions in everyday life, and will use both versions. It seems totally inappropriate to create work for most editors in order to solve a problem that doesn't even exist. I hope this is the last poll we get on this issue. Four polls within 6 months is rather too much. Each time the consensus is that this is not needed and not wanted. Stop with the polls already! SilkTork *^YES! 16:20, 31 March 2009 (UTC)[reply
     ]
118. Oppose Marking up every date in every article (millions of them) - just so that people can choose between day-month and month-day? Madness! WAS 4.250 (talk) 16:26, 31 March 2009 (UTC)[reply]
119. Oppose this seems like a solution in search of a problem. Something I think people are forgetting is that the vast majority of our readers are unregistered. The people for whom this is supposed to provide the most benefit aren't even going to know it's going on. Leave it as it is, and let an
     WP:ENGVAR type solution take care of it. Parsecboy (talk) 16:30, 31 March 2009 (UTC)[reply
     ]
120. Oppose. I am most persuaded by There is no problem to solve. I was concerned about the "metadata" argument, but I think it is properly answered above in the Metadata fallacy section of the "statement against". —Dominus (talk) 16:32, 31 March 2009 (UTC)[reply]
121. Oppose There is no problem to solve. I don't think it will ever work for non-logged-in readers, so is not worth doing. It will never work in all grammatical situations. --Jc3s5h (talk) 16:33, 31 March 2009 (UTC)[reply]
122. Oppose There is no problem to fix. There are other ways to deal with date meta-data. Gwen Gale (talk) 16:38, 31 March 2009 (UTC)[reply]
123. Oppose This is a weak solution without a problem. Most readers are not even logged in anyway. Richard75 (talk) 17:22, 31 March 2009 (UTC)[reply]
124. Oppose I agree with Richard75; I don't think this will accomplish much except put off new editors and make other editors spend time making minor edits, to very minor effect. Ricardiana (talk) 17:29, 31 March 2009 (UTC)[reply]
125. Oppose. Most readers aren't logged in, and the different date formats are easy to understand anyway. In addition, anything that reduces the sea of blue in articles is welcome. This is a solution looking for a problem. SlimVirgin ^{talk|contribs} 17:30, 31 March 2009 (UTC)[reply]
126. Oppose. What the Statement Against says - specifically, there is no problem to solve. Furthermore the solution is arduous for new editors, and potentially error-prone. David Brooks (talk) 17:40, 31 March 2009 (UTC)[reply]
127. Oppose – TheLeftorium 18:03, 31 March 2009 (UTC)[reply]
128. Oppose - just solving problems that don't exist. We have plenty of real problems to solve and articles to expand. The Rambling Man (talk) 18:10, 31 March 2009 (UTC)[reply]
129. Per Steve Crossin. --Nemo bis (talk) 18:12, 31 March 2009 (UTC)[reply]
130. Oppose - Seems like making mountains out of molehills, as well as a solution in search of a problem. In general I'm against adding additional layers of complexity (code) to basic things like simple text, which just alienates new users & leads to technical screwups in editing. "March 31, 2009" and "31 March 2009" mean the same thing, and no one needs autoformatting to derive the same meaning from either format. --IllaZilla (talk) 19:01, 31 March 2009 (UTC)[reply]
131. A few comments: The Template:Date is an intriguing addition to this discussion, and made me think long and hard about this. I've read dozens of the comments in these threads, and agree that many people opposing seem to have the wrong idea that this sub-poll is about 'linking'. I strongly support the idea of obtaining meta-data, without blue links. But, am conflicted about autoformatting - partially because who decides whether mdy or dmy is the default? and partially because more wikicode complexity should be avoided if possible. I (currently) think the styling/formatting of our dates should be treated like ENGVAR (because the world is diverse, and we currently reflect that), like our FAs, like the German-wiki (no dates linked), and that an alternative technical solution should be found for extracting metadata - one that doesn't impact readers or editors at all. So, a weak oppose, I guess. But if no other solution can be developed, then the lure of "automated time lines" generation is enough to make me reconsider in the future. Any demos available for that? -- Quiddity (talk) 19:05, 31 March 2009 (UTC)[reply]
132. Oppose - metadata is important, but this is not the way to do it. Solution in search of a problem. – Quadell ^(talk) 19:39, 31 March 2009 (UTC)[reply]
133. Oppose. It has benefited maybe a few thousand users at the expense of thousands (millions?) of man-hours and server resources. Autoformatting is, in simple terms, coo coo bananas. --- RockMFR 19:48, 31 March 2009 (UTC)[reply]
134. Oppose. It's a tiny detail that loads us thousands of links. Moreover, I think it's weird we demand US oriented articles to be written in US spelling and we allow date autoformating. Date format should apply with the spelling. -- Magioladitis (talk) 19:52, 31 March 2009 (UTC)[reply]
135. Oppose. --DuLithgow (talk) 21:01, 31 March 2009 (UTC)[reply]
136. Oppose. We should stop date linking for the sake of auto-formatting. There may be other, less intrusive, ways to auto-format dates. — Xavier, 21:29, 31 March 2009 (UTC) Update, to an editor's request, and to make myself clear: I'm opposed to any kind of markup for the sole purpose of date auto-formatting. — Xavier, 21:10, 3 April 2009 (UTC)[reply]
137. Oppose. I think the real giveaway here is that statement that autoformatting has "been an option in operating systems for decades". Yes, this is true, because decades ago most operating systems displayed dates in numeric format where there was genuine ambiguity about the meaning of the date if it was in the first twelve days of the month. This seems to have led to an assumption in nerdland that there there is also an ambiguity/readability issue even when the month is spelt out. We shouldn't be following operating systems, but real-world information sources. I have never come across a web information source or news provider that worries about this enough to give readers an option as to how to display the date, so for us to worry about the issue is to engage in
     Phil Bridger (talk) 23:02, 31 March 2009 (UTC)[reply
     ]
138. Oppose. -- So little value added, so much time wasted. Ground Zero | t 23:36, 31 March 2009 (UTC)[reply]
139. Oppose. Formatting of dates adds nothing to any article. We should prohibit wikilinking dates. This proposal moves in the other direction. SMP0328. (talk) 00:25, 1 April 2009 (UTC)[reply]
140. Oppose — Autoformatting is as onerous as date linking, so far as the editor is concerned. With my typing skills, it would amount to just another opportunity to make mistakes. PKKloeppel (talk) 01:10, 1 April 2009 (UTC)[reply]
141. Oppose no need for it.
     Kablammo (talk) 01:23, 1 April 2009 (UTC)[reply
     ]
142. Oppose—intrusive, pointless. Ceoil (talk) 01:29, 1 April 2009 (UTC)[reply]
143. Oppose—True cwap. LilHelpa (talk) 01:31, 1 April 2009 (UTC)[reply]
144. Oppose—links should lead users to useful content. Date links do not. -- Ssilvers (talk) 05:29, 1 April 2009 (UTC)[reply]
145. Oppose—There's no use for autoformatting. I don't see the problem here. --Popiloll (talk) 06:53, 1 April 2009 (UTC)[reply]
146. Oppose— Per
     WP:OVERLINK. Cluttering up pages with irrelevant links serves no purpose. I know that when I was a new user, I often clicked on these date links expecting some relevant information, and was always disappointed to find none. Gatoclass (talk) 07:28, 1 April 2009 (UTC)[reply
     ]
147. Oppose—Anderson above mentions "irresoluble grammatical difficulties", here's another. Take the phrase an August 7 decision change format and you have to have a 7 August decision. {{#formatdate:}} cannot even handle ranges yet; can we expect ever to have it handle this? But let's suppose for the moment that these problems are solved (... it's the year 2187 ...) autoformatting brings with it another ill. By displaying dates in the user's preferred format underlying inconsistency can be hidden from the very people who would otherwise be fixing such problems. Perhaps a page-by-page default system could be implemented to avoid this. Thus WikiMedia's autoformatting has a fair way to go until it is a realistically workable solution. Is it worth the trouble? Is there any great difference between looking at the other sides date formatting as opposed to looking at their spelling? Date formatting is just one aspect of dialect, let it thus go under ENGVAR ... or at least until someone comes up with a workable solution to that. JIMp _talk·cont 08:07, 1 April 2009 (UTC)[reply]
148. in the words of Donald Knuth, "premature optimization is the root of all evil". But I would be all for a smart client-side date autoformatting tool, e.g. in the shape of a firefox plugin. --
     dab (𒁳) 08:34, 1 April 2009 (UTC)[reply
     ]
149. Oppose—Not a benefit that editors see date formats that vary from that which the general reader sees. We are all flexible enough to recognize and understand dates in various formats. —Mattisse (Talk) 11:43, 1 April 2009 (UTC)[reply]
150. Oppose. I've happily gone my whole life without realising that this is an issue, or that there are (supposedly) country-specific preferences. I read "April 1" and "1 April" equally easily -- the difference doesn't even register. As many others have said, I don't see that there is a problem to solve, and I oppose the unnecessary addition of markup that simply serves to make editing more cumbersome, cryptic, error-prone and time-consuming. Matt 11:55, 1 April 2009 (UTC).
151. Oppose I don't really see the point in this VJ (talk) 12:42, 1 April 2009 (UTC)[reply]
152. Oppose - Not much gain (is there any gain at all?), and huge cost. I as an editor don't want to see the page source full of even more cryptic tags. And I'm a software engineer who have been programming date handling for databases every now and then since 1994 (as my paid day job), I know how complex it is to handle dates. The MediaWiki devs should spend their time on more productive issues. They haven't even had time to fix the #time parser function yet, it has known bugs. But they don't know what causes those bugs. And now you guys want to add complex date handling to MediaWiki? --David Göthberg (talk) 17:20, 1 April 2009 (UTC)[reply]
153. Oppose - Date formatting makes Wikipedia editing hard :^( Fightin' Phillie (talk) 17:58, 1 April 2009 (UTC)[reply]
154. Oppose - Autoformatting adds complexity and it does not solve any important problem. EdJohnston (talk) 19:39, 1 April 2009 (UTC)[reply]
155. Oppose – I want to be on the winning side for once. Brianboulton (talk) 23:47, 1 April 2009 (UTC)[reply]
156. Oppose - What next, the "autospell extension" that changes aluminium to aluminum or lift to elevator based on the users preferences? Needless bureaucracy where none is required. SFC9394 (talk) 00:03, 2 April 2009 (UTC)[reply]
157. Oppose - I basically think it is a waste of manpower to make the overhaul.--
     WP:LOTM) 00:12, 2 April 2009 (UTC)[reply
     ]
158. Oppose - Too much work for the gain, though I cannot agree with those who say the existing date formats pose no problem. The ISO dates are a pain in the neck and the problem for dates before the 12th of the month is real and needs to be addressed by editors. But i cannot see that autoformatting is a solution. hamiltonstone (talk) 00:45, 2 April 2009 (UTC)[reply]
159. Oppose - There's no real problem to fix; most people can understand both forms of dates. It essentially seems like a lot of work for next to no real gain. —LedgendGamer 02:11, 2 April 2009 (UTC)[reply]
160. Oppose - There's really no need for it. 2 April or April 2, not all that different than the difference between color and colour. Simple difference depending on your dialect. Not a big deal in my view. --Sable232 (talk) 02:38, 2 April 2009 (UTC)[reply]
161. Oppose Date formatting would give complex wikitext with the only benefit that sensitive people used to "April 1" could hope to never see "1 April", and vice versa. Complex wikitext makes it harder to focus on the important content in an article. Date formatting would be a pointless overhead on the WP servers, and a frivolous time-waster for editors. Johnuniq (talk) 02:39, 2 April 2009 (UTC)[reply]
162. Oppose - Wikitext syntax should be kept as simple as possible to encourage contributions by new users. Complicating syntax for the sole benefit of registered editors is anathema. AxelBoldt (talk) 02:41, 2 April 2009 (UTC)[reply]
163. Oppose - I read very easily any date in any format and think that Date formatting is just unnessisary work Bob man801 (talk) 04:28, 2 April 2009 (UTC)[reply]
164. Oppose. I was going to "vote" neutral, but I changed my mind. In principle, I like the idea of giving users the option of displaying dates in the manner they prefer. However, I doubt that more than a very small fraction of Wikipedia users have ever taken advantage of this feature (or would do so in the future). In order to benefit from date formatting, a user must be registered and logged in, and must have set the preference for date display. However, my guess is that the vast majority of users who access Wikipedia while logged in are logged in primarily to edit (not to read articles) and don't care about date display (because they are at Wikipedia primarily to edit, not to read articles). Accordingly, I estimate that very few users actually benefit from date formatting. The small benefit of autoformatting does not justify the resources that would be expended to implement it (I figure autoformatting would consume volunteer time and space in articles, and it would intimidate a certain fraction of prospective volunteers, preventing them from volunteering). --Orlady (talk) 04:40, 2 April 2009 (UTC)[reply]
165. Oppose When I first discovered that I could autoformat dates through my user preferences, I did it immediately. However, then I discovered that what I was seeing on an article was not what I was seeing when I edited the page. As editors, it is our responsibility to optimize the encyclopedia for readers, the vast majority of whom do not have access to autoformatting, because they are not registered. Autoformatting acts as an impediment to editors, misleading them as to what readers are seeing, and as such is undesirable.--Aervanath (talk) 05:14, 2 April 2009 (UTC)[reply]
166. Oppose (1) There is no problem to be solved here (2) We have too much intimidating markup already for new users to handle, and {{#formatdate|March 11, 2009}} is just unacceptable. (3) editors shouldn't be seeing something different from what the vast majority of the readers will see. Shreevatsa (talk) 05:28, 2 April 2009 (UTC)[reply]
167. Oppose as unnecessary. Different date formats are like regional variations in spelling: they're very easy to get used to. What's next—autoformatting to change "color" to "colour"? Rivertorch (talk) 05:31, 2 April 2009 (UTC)[reply]
168. Oppose Editors should be presented with the same view as the general readers.
     Taemyr (talk) 05:55, 2 April 2009 (UTC)[reply
     ]
169. Oppose Per Sept, Sandy, Karanacs and others.--Yannismarou (talk) 08:03, 2 April 2009 (UTC)[reply]
170. Oppose. Autoformatting requires more work, and i see no benefit to readers at all. Everyone understands dates in both common formats. There is already to much syntax required to fullfil MoS requriments for FAs, and anyone that thinks people will not argue over the removal/adding of formatting just as much as national date formats underestimates the desire of editors for pointless warring. Simply having rules for dates as with Engvar is the way to go.134.169.58.89 (talk) 09:12, 2 April 2009 (UTC)[reply]
171. Oppose. It's not worth the required effort. Makes editing harder, with at most doubtful benefit to general readers. −Woodstone (talk) 11:20, 2 April 2009 (UTC)[reply]
172. Oppose. No. I certainly don't want my markup to move even further from natural language, and the inevitably limited deployment of the templates will force any automated date-based tool to parse non-templated dates. And what would an automated tool do? It is unlikely to be able to tell which dates are closely linked to the article contents and which, say, describe the process of the article topic becoming well-understood.Avram (talk) 16:45, 2 April 2009 (UTC)[reply]
173. Oppose, per Pmanderson, Karanacs, and Gatoclass. --Rosiestep (talk) 17:32, 2 April 2009 (UTC)[reply]
174. Oppose There should be no difference between casual and registered users.--
     talk) 18:57, 2 April 2009 (UTC)[reply
     ]
175. Oppose ENGVAR is the best and simplest solution to this non-problem. -- Mattinbgn\^talk 20:46, 2 April 2009 (UTC)[reply]
176. Oppose Number 130 says it better and I don't see anyone comment the fact the genealogists in USA are using day/full month/year far more than the other one. Even FamilySearch use this throughout. I use European dating. Samuelsenwd (talk) 21:49, 2 April 2009 (UTC)[reply]
177. Oppose. I suspect most readers don't care whether an article says April 2 or 2 April; the order is trivial enough not to warrant the additional coding complexity. Steve ^{T • C} 22:02, 2 April 2009 (UTC)[reply]
178. Oppose this unnecessary added complexity.—S Marshall ^Talk/_Cont 22:24, 2 April 2009 (UTC)[reply]
179. Oppose - Our own Chief Technical Officer says: "My personal recommendation would be to remove all date autoformatting." THis whole thing is complex and laborious with little to no added benefit. As long as a date is given, I don't care if it's written April 2, 2009, 2 April 2009, or the second day of the month of April of the year 2009.
     talk) 23:22, 2 April 2009 (UTC)[reply
     ]
180. Oppose. Do I have to repeat the arguments? -- Taku (talk) 01:47, 3 April 2009 (UTC)[reply]
181. Oppose - We should not manipulate article text to the animosities of certain user groups, especially when there is absolutely no problem with understanding any date variant. Cacycle (talk) 02:50, 3 April 2009 (UTC)[reply]
182. Oppose. I never really saw any advantage in autoformatting, and the implementation (so far) has done more harm than good. Yilloslime ^T_C 04:33, 3 April 2009 (UTC)[reply]
183. Oppose, if as an unregistered user I'm allowed to do so. That's one of my reasons for objecting: people shouldn't be wasting time on this when it won't benefit users like me. In addition any amount of additional markup on something as short as a date is unwieldy. And it's not just a matter of rendering "3 April 2009" or "April 3, 2009"; if this comes up within a sentence a second comma may be required in the second format, i.e. "April 3, 2009,". Even if we provide options for this, many people used to other formats will get it wrong. --208.76.104.133 (talk) 05:15, 3 April 2009 (UTC)[reply]
184. Oppose. Several reasons given strike me as sensible, particularly the issue of IP users not seeing the formatted date. Mike Christie (talk) 10:57, 3 April 2009 (UTC)[reply]
185. Oppose. Although I'm usually in favour of complicated technical solutions to non-problems (especially when I'm supposed to be doing something productive), this one is going to cause more grief than it's worth. As long as we don't use purely numeric dates, there's no ambiguity and the order (4 January vs January 4) doesn't matter at all. One caveat though - if we are using numeric dates somewhere (infoboxes, for example) they should be in a sensible date format, either YMD or DMY, with four digit years. I would support autoformatting to enforce this, but as far as I'm aware most templates do already. Orpheus (talk) 11:00, 3 April 2009 (UTC)[reply]
186. Oppose - I don't feel very strongly on this, but on reflection it's a pretty clear decision. Autoformatting is a nice idea in theory, but in practice delivers a mild benefit to a very small number of comitted and involved editors (who are clued-in enough to set preferences) whilst delivering an equally mild detriment to the vast bulk of our readers. A nice idea, but the implementation didn't live up to what we hoped for, and we're hopefully a mature enough project that we can drop things that don't help us.
     talk | 15:17, 3 April 2009 (UTC)[reply
     ]
187. Oppose -- We don't have nor want automatic British/American English spelling. This is analogous. -- KelleyCook (talk)
188. Oppose - the Manual of Style doesn't allow or recommend confusing formats such as 03/04/2009, so there should be no confusion for human readers. Only logged-in editors with preferences set are likely to be confused - or cause confusion - because they won't see what a passing reader does. 21Bede (talk) 15:51, 3 April 2009 (UTC)[reply]
189. Oppose. primarily because this is just a simple case of
     WP:ENGVAR. The supporters that say that Wikipedia should present dates consistently conveniently forget that we don't spell colour/color or meter/metre consistently across the encyclopedia either. The example that Britannica uses consistent date formats is just an extension of the fact that they use consistent British English spelling. The thing that we need to do is to have consistent date formats within each article and plain text dates can solve that without the need for additional markup. --seav (talk) 16:38, 3 April 2009 (UTC)[reply
     ]
190. Oppose - on the KISS principle and because of all the issues facing Wikipedia (which is asking for donations to keep itself going) and its volunteers, this seems very low priority. Further, if anything at all is needed from editors to attend to this issue, it's not worth it. In other words, I wouldn't expend any sort of resources (even this poll seems time-consuming) and in my opinion, as a fairly new Wikipedian, Wikipedia is already bogged down in an enormous number of these kinds of discussions. The current system works, all editors know they are supposed to be consistent within articles, and as a member of the copyediting team, so far I rarely find that any article is inconsistent - but if it is, tag it for copyediting and let it go. Nothing requiring additional mark-up should be added to Wikipedia until a larger number of people are familiar with current mark-up.Levalley (talk) 18:20, 3 April 2009 (UTC)[reply]
191. Oppose — Malik Shabazz (talk · contribs) 19:41, 3 April 2009 (UTC)[reply]
192. Oppose. Malinaccier (talk) 19:47, 3 April 2009 (UTC)[reply]
193. Oppose Autoformatting hassle isn't worth the effort so some registered editors can see only one kind of date format. Everyone else will be seeing two formats depending on which article they land on. That is no big deal. Deegee375 (talk) 21:13, 3 April 2009 (UTC)[reply]
194. Oppose As far as I can see only logged in users would be able to see it. If that's the case then it simply should not be introduced. Peanut4 (talk) 21:52, 3 April 2009 (UTC)[reply]
195. Oppose, not a useful addition. --Peta (talk) 08:15, 4 April 2009 (UTC)[reply]
196. Oppose --Alex Holcombe (talk) 08:43, 4 April 2009 (UTC)[reply]
197. Strongly oppose—Autoformatting Is For Markup Lovers. The sane (and productive) expend their energy much more wisely.—DCGeist (talk) 09:01, 4 April 2009 (UTC)[reply]
198. Oppose - No, No, a thousand times No! Autofotamting is to be avoided at all costs. Also its evil and it must die! — Preceding
     talk • contribs
     )
199. Oppose Autoformatting would overcomplicate things, and the benefits we would get from it are very minor IMO. Let's simplify the markup as much as possible and not the other way! Laurent (talk) 12:24, 4 April 2009 (UTC)[reply]
200. Oppose I just don't see what the big issue is - I'm from the UK (and prefer UK date formatting personally) but I can easily understand the American format (Month Day, Year - maybe not so much M-D-Y) or the ISO format (YYYYMMDD). ~~ [ジャム]^[t - c] 14:14, 4 April 2009 (UTC)[reply]
201. Oppose: Autoformatting does nothing for the vast majority of WP readers, only those who a) are logged into real accounts here, and b) have bothered to set autoformatting options. The autoformatting "feature" causes experienced editors (i.e. those likely to fix article inconsistencies) to rarely notice inconsistent dates within an article, including ISO formatting, that are presented inconsistently to most readers. — SMcCandlish [talk] [cont] ‹(-¿-)› 18:22, 4 April 2009 (UTC)[reply]
202. Oppose Keep it simple, choose an appropriate format per
     WP:ENGVAR, we don't need a technical solution to cope with using an appropriate date format. Struway2 (talk) 20:19, 4 April 2009 (UTC)[reply
     ]
203. Oppose - There is no real point, it causes problems, and it is not worth the effort and disputes. Ottava Rima (talk) 20:21, 4 April 2009 (UTC)[reply]
204. Oppose. I don't see how the result is worth the cost. bibliomaniac15 23:45, 4 April 2009 (UTC)[reply]
205. Oppose. Never did see sense in it. --Moni3 (talk) 03:18, 5 April 2009 (UTC)[reply]
206. Oppose - Anything that requires digging through preference options will only be used by a tiny handful of users. Furthermore, the vast majority of our users aren't even registered. Much work, little benefit. Shoemaker's Holiday (talk) 06:02, 5 April 2009 (UTC)[reply]
207. Oppose This is a solution in search of a problem. Just keep it consistent within each article. Joshdboz (talk) 07:13, 5 April 2009 (UTC)[reply]
208. Oppose Let the editors working on an articlr agree on consistent formats. No need for an automatic process, which could well produce more problems. Jezhotwells (talk) 12:11, 5 April 2009 (UTC)[reply]
209. Oppose Do not add complexity where it is not needed and is prone to errors and misinterpretations.--Avg (talk) 15:41, 5 April 2009 (UTC)[reply]
210. Oppose Inelegantly solves what needn't be. --Thomas B♘talk 16:53, 5 April 2009 (UTC)[reply]
211. Oppose. Arguments against really sum it up completely. — Σxplicit 19:02, 5 April 2009 (UTC)[reply]
212. Oppose: Don't think dates should be linked, looks messy. Ryan4314 (talk) 19:11, 5 April 2009 (UTC)[reply]
213. Oppose - I supported the first time, when first brought up, I support it now. --  ThinkBlue  (Hit BLUE) 22:32, 5 April 2009 (UTC)[reply]
214. Oppose per excellent arguments. As Tony said, simplicitty without sacrificing quality is key; sadly, autoformatting has the potential to violate both. — Deckiller 23:43, 5 April 2009 (UTC)[reply]
215. Oppose: I believe we should strictly follow ISO standard in all and any cases not just with dates but time, units and everything else. Could this be achieved autoformatting would be a trivial task of simple pattern recognition that even could be done locally with java scripting, the only special tag needed is in the case when a format should not be localized. The reason I oppose this is that I think that all form of localization should be in a general format, to implement a special case for dates would be confusing and will work against a uniform standard in the raw text format. I understand that "correcting" everything to ISO standard is a monumental task however I think the benefit outweighs the cost and we do not lack the manpower to do so. Brainz (talk) 04:22, 6 April 2009 (UTC)[reply]
216. Oppose - Only a small subset of Wikipedia readers will benefit from auto formatting and the complex syntax deters new editors. -- SWTPC6800 (talk) 04:27, 6 April 2009 (UTC) Each month Wikipedia has about 56 million unique viewers. There are only 180 thousand Wikipedians that set a data preference so at best it is 1 out of 300 viewers (0.3 %) that will benefit from date autoformatting. -- SWTPC6800 (talk) 02:41, 12 April 2009 (UTC)[reply]
217. Oppose - I disagree with differing formats for registered v. non-registered.
     chitchat 04:57, 6 April 2009 (UTC)[reply
     ]
218. Oppose - Lack of impact/beneficiaries compared to amount of work to implement. Remember cost/benefit. Annihilatron (talk) 13:28, 6 April 2009 (UTC)[reply]
219. Oppose - Linking dates for the purpose of reformatting breaks the typical user's concept of linking and they also end up with tons of irrelevant links all over the page. The proposed replacement is just as bad. People who absolutely need to have date reformatting, should do it with a personal javascript or a browser plugin. -- Austin Murphy (talk) 14:26, 6 April 2009 (UTC)[reply]
220. Oppose - No reason why date format cannot be done in the same way as spelling and other regional differences. Richard New Forest (talk) 14:52, 6 April 2009 (UTC)[reply]
221. Oppose per #1 and per if it crashes the server...
     miranda 16:33, 6 April 2009 (UTC)[reply
     ]
222. Oppose in the cost-benefit analysis, the small cost of added complexity outweighs the almost-indistinguishable-from-zero possible benefit. Knepflerle (talk) 16:37, 6 April 2009 (UTC)[reply]
223. Oppose This is a waste of resources imho.
     talk) 17:03, 6 April 2009 (UTC)[reply
     ]
224. Oppose KISS. Fredrik Johansson 17:28, 6 April 2009 (UTC)[reply]
225. Oppose Anyone intelligent enough to work through the configuration options will have no problem interpreting various date formats. —Danorton (talk) 18:10, 6 April 2009 (UTC)[reply]
226. Oppose Helps few, makes it less likely that experienced editors will notice formatting problems, confusing syntax makes editing even harder for new editors. Calliopejen1 (talk) 18:25, 6 April 2009 (UTC)[reply]
227. Oppose Luxury standardizing with extremely little benefit. Peter ^Isotalo 18:33, 6 April 2009 (UTC)[reply]
228. Oppose why does everything have to be standardised, no need not necessary. Edmund Patrick – confer 19:01, 6 April 2009 (UTC)[reply]
229. Oppose There is no problem, a date is a date. It does not matter dmy or ymd, unless you are one of the people who thinks that speaking louder to someone who doesn't speak your language makes them understand :>--
     talk) 19:47, 6 April 2009 (UTC)[reply
     ]
230. Oppose most readers do not see it, pointless in many/most cases --KarlFrei (talk) 20:18, 6 April 2009 (UTC)[reply]
231. Oppose very marginal improvement (as either date format is perfectly comprehensible, and the majority of readers do not use accounts) versus a huge dilution of the prominence of valuable blue links. The articles on days and years, while they may serve some purpose, are NEVER a useful link in the context of any article. I believe the consensus against this is strong, but even stronger when one examines the views of users that have either written a featured article or worked as a reviewer in that process. Savidan 20:58, 6 April 2009 (UTC)[reply]
232. Oppose if it ain't broke, don't fix it. Dlabtot (talk) 00:19, 7 April 2009 (UTC)[reply]
233. Oppose — Negative cost/benefit (cost here in terms of nuisance, effort, and time). It's a neat capability, to be sure, but it is the answer to a question that doesn't really need asking, akin to hiring a translator to translate a speech being made by an Australian to an American audience or vice versa. Nobody's access to Wikipedia is hindered by encountering dates in this format versus that format; let's focus our efforts on implementing features to expand accessibility where such expansion is actually needed. —Scheinwerfermann ^T·_C00:35, 7 April 2009 (UTC)[reply]
234. Oppose. The push for autoformatting is an understandable but inappropriate response to Wikipedia's inherent complexity, and to the diversity of Wikipedia's readership. It exemplifies an insidious technocratic, "high-priestly" approach, by which the great majority of ordinary editors are disadvantaged and discouraged. The supposed benefits are not worth the concession that it requires – to a vocal minority who fail to understand the human side of involvement in Wikipedia. Perhaps in future the project will rest on more rational technical foundations; till then, this sort of initiative is to be resisted as unworkable. For both users and editors we need to keep things straightforward and comprehensible.–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 07:19, 7 April 2009 (UTC)[reply]
235. Oppose - quite unnessecary. PluniAlmoni (talk) 09:43, 7 April 2009 (UTC)[reply]
236. "Oppose", I suppose. Actually I'm not at all opposed to the general concept of date autoformatting, unlike, say, Noetica, as I interpret his/her response close above. However, in effect we're not asked our opinions on the general concept but instead on the implementation that we're likely to get. This, the implication we're likely to get, I oppose, for reasons pointed out by Jimp in vote (or if you prefer "!vote") circa 146 above. Of course yet more work could go into perfecting a context-sensitive algorithm, and this might even work, eventually; but that would seem a bizarre expenditure of time, effort, and perhaps also processing power, as explained by Largo Plazo in vote circa 56 above. (NB my vote has nothing to do with date linking, which of course (a) sucks, but (b) is beside the point here.) -- Hoary (talk) 09:52, 7 April 2009 (UTC)[reply]
237. Oppose. Support Jimp (147). The "for" reasons are very weak. Platia (talk) 14:06, 7 April 2009 (UTC)[reply]
238. Oppose Seems like far too much effort and risk for something so trivial. If implemented, it could be followed by proposals for auto-formatting British vs. US spellings, etc. How boring. One delight of Wikipedia is its heterogeneity - it's also the nature of the English language. Why try to squeeze that heterogeneity into a uniform box? Pinkville (talk) 14:56, 7 April 2009 (UTC)[reply]
239. Oppose In isolation, auto-formatting is potentially neat. When measured against its downsides, however, it falls short. The very minor upsides are not worth all of the hassle. --Cyde Weys 15:39, 7 April 2009 (UTC)[reply]
240. Oppose Seems like a lot of effort to solve a minor issue, and another step on the learning curve for new editors. What's next, an ENGVAR-corrector? Acroterion _(talk) 18:31, 7 April 2009 (UTC)[reply]
241. Oppose. This is supposed to be The Encyclopedia anyone can edit, not The Encyclopedia anyone willing to learn esoteric markup rules can edit. We're already too far down this particular slippery slope, I think. Jgm (talk) 20:45, 7 April 2009 (UTC)[reply]
242. Oppose per Awadewit.
     Nev1 (talk) 21:33, 7 April 2009 (UTC)[reply
     ]
243. Oppose as Jgm above --Doug (talk) 09:05, 8 April 2009 (UTC)[reply]
244. My stance remains against date auto-formatting in general; nothing has really changed with the proposed "link-less" system, and I'm unconvinced that any suggested system could solve the problems inherent with this type of treatment.
     1. One of the arguments in favour of auto-formatting is that it would provide a uniform style of dates that many editors desire. I cannot understand, however, what sense that would make when many other aspects of an article would be clearly following the conventions of a different dialect of the English language—this system would create clashes within articles, and unless we are discussing adopting a single date format everywhere, speaking of uniformity in this context is suggestive of tunnel vision.
     2. Another argument is that DA prevents petty arguments. We are supposed to be writing an encyclopaedia for the world at large, not just for the editors. We are all working on one project, so we should be seeing the same things that our readers see. It is one thing to customise things like time zone in the talk and project pages, but in the mainspace, I hold this as a non-negotiable principle.

     I could say much more on DA, but the bottom line is: we don't need it, and we'll be better off without it. Waltham, The Duke of 14:41, 8 April 2009 (UTC)[reply]

245. Oppose Kennedy ^(talk) 15:08, 8 April 2009 (UTC)[reply]
246. Oppose I find it useful to see the date format an editor uses to get a rough idea which side of the pond they're on. Plus, autoforatting dates is really, really minor. --Armchair info guy (talk) 15:11, 8 April 2009 (UTC)[reply]
247. Oppose Keep Wikipedia as simple and straightforward as possible. Apuldram (talk) 17:32, 8 April 2009 (UTC)[reply]
248. Oppose The oppose box sums it all up perfectly for me. I just don't see it as necessary, and it can be complicated and confusing for newcomers. --GedUK  19:10, 8 April 2009 (UTC)[reply]
249. Oppose I do not see why it is neccesary and I can see how it hurts newcomers. Zerter (talk) 19:19, 8 April 2009 (UTC)[reply]
250. Vote for this (opposing an opposing position is nonsense). Please stop bickering and voting endlessly over something of such minor importance. Brion Vibber's solution is fine by me, as are any number of variants. Nice though it is, we don't need autoformatting of dates, and apparently there isn't consensus to do that. There would be no consensus for autoformatting of spelling, surely. Enough said, end of story. Geometry guy 20:57, 8 April 2009 (UTC)[reply]
251. Oppose Confusing and unnecessary. Wikipedia is a thing in and of itself. If you want a completely consistent encyclopedia, do what regular reference books do, appoint a panel of editors who edit it all and give up on the idea of a work that anyone can edit. Wikipedia has too many editing rules as it is. Fijagdh (talk) 21:10, 8 April 2009 (UTC)[reply]
252. Oppose Everyone should use YYYY-mm-dd format. Python eggs (talk) 04:39, 9 April 2009 (UTC)[reply]
253. Oppose As well as the many other reasons mentioned, I think it adversely impacts readability. Hohenloh ⁺ 19:45, 9 April 2009 (UTC)[reply]
254. Oppose I acknowledge that this might be beneficial for some, but overall will probably bring more evil than good. Húsönd 20:39, 9 April 2009 (UTC)[reply]
255. Oppose I imagine that after a tremendous effort, and the burden of an ongoing cost to many editors and IT, the entire encyclopedia from a readers point-of-view will be, all other things held equal, mostly unchanged. - only editors with negative experiences and ongoing frustrations would be aware of it a month or so after the unvieling. --Karbinski (talk) 20:45, 9 April 2009 (UTC)[reply]
256. Oppose having got used to un-autoformatted dates, the advantages of linking dates to date articles is outweighed by the cleaner appearance without trivial blue links for unimportant dates. I've never set the preferences, as it's always better in my opinion to see the dates formatted according to the preferences of the relevant country, as with spelling. Too much effort and hackery to fix a non-problem of dates in two commonly recognisable arrangements. . dave souza, talk 21:57, 9 April 2009 (UTC)[reply]
257. Strong Oppose A trivial detail. Next should there be templates like {{British|colour|color}}? -- NipplesMeCool (talk) 23:38, 9 April 2009 (UTC)[reply]
258. Oppose Unnecessary, trivial. I see no benefit for the effort involved. Hohum (talk) 17:19, 10 April 2009 (UTC)[reply]
259. Oppose The solutions are more bothersome than the problem. There is no strong need for autoformatting. --GGG65 (talk) 18:34, 10 April 2009 (UTC)[reply]
260. Oppose If it takes any of the following: one millisecond extra loading time, if it adds extra wikilinks to a page, if it adds problems for old or new or alternative browsers, if it makes a demand on the sometimes already overtaxed wiki servers, if it confuses editing by adding more than 1 or 2 additional signs (i.e. something like #autoformat), this option would be unacceptable to me. As I don't see the problem, I will only accept a 1 in billion chance of negative effets of this. I don't believe this can be guaranteed, hence oppose. Arnoutf (talk) 19:41, 10 April 2009 (UTC)[reply]
261. Oppose Date autoformatting can easily end up as an excuse for editors to impose difficult to understand formats in the normal text, justifying this by saying "if you do not like it, just set your date autoformat preferences". Wikipedia pages should be written so that normal people can understand them - they should not need to be logged in members with various wikipedia-only preferences set up.--Toddy1 (talk) 21:07, 10 April 2009 (UTC)[reply]
262. Oppose Linking dates is pointless silliness that sends the wrong message and is ugly. 2005 (talk) 23:01, 10 April 2009 (UTC)[reply]
263. Oppose...BIG TIME We love over-complicating things here, don't we? Do U(knome)? ^yes..._{or no} 01:28, 11 April 2009 (UTC)[reply]
264. Oppose A waste of time for editors with very little benefit for anyone. McKay (talk) 01:57, 11 April 2009 (UTC)[reply]
265. Oppose Just doesn't work and is hardly necessary. --Itub (talk) 02:37, 11 April 2009 (UTC)[reply]
266. Oppose It's a waste of time even to discuss this. (1) Wikipedia can live without absolute standards when there is such variety of actual usage. (2) Users are intelligent enough to manage this for themselves. (3) Furthermore, in exact quotation, the format should be exactly what it is in the quoted material. (4) Finally, all this effort should be devoted to improving numerous articles in which a non-expert reader is immediately lost, such as many on pharmaceuticals, Chinese legendry, Indian history, diseases, weather, and so forth. Zaslav (talk) 06:23, 11 April 2009 (UTC)[reply]
267. Oppose, but I really think a proper consensus should be made as to which date format we use in prose, refs, etc. Corn.u.co.pia • Disc.us.sion 07:32, 11 April 2009 (UTC)[reply]
268. Oppose I find the different date formats much less noticable than the different spelling systems which we can live with. There is nothing wrong with some diversity. This is not the Simple English wiki.--Charles (talk) 10:28, 11 April 2009 (UTC)[reply]
269. Oppose I agree it makes no real difference, all it does is add extraneous formatting or the annoying links everywhere. - _J.Logan`^t: 11:17, 11 April 2009 (UTC)[reply]
270. Oppose It is too much effort for something trivial. Out of all the complaints I have heard about Wikipedia, there has never been a "The date is the wrong way around" MortimerCat (talk) 11:23, 11 April 2009 (UTC)[reply]
271. Oppose - Same reasons as I noted last time, auto-formatting dates often makes for sloppy looking articles when you consider the need for date spans. Thus, we should format dates based on the topic just like
     vecia 15:22, 11 April 2009 (UTC)[reply
     ]
272. Oppose  “Customizing the interface” is a misleading red herring – your operating system's preferences don't rewrite web pages and articles for you. Editors write the text, readers read it. The editor uses wikitext to control the output, and a machine shouldn't be trying to improve it by rewriting it based on wishful thinking. The GPL I signed doesn't give a machine the right to correct my contribution, even a bit. What next, build in a pirate-talk filter to give “users” more “personal control?” —Michael Z. 2009-04-11 16:11 z
273. Oppose  This will get more complicated, consume our time and attention, with little or no benefit. I've seen edit wars result from "fixing" date-ranges due to date auto-formatting. We have more important things to do. --A D Monroe III (talk) 18:47, 11 April 2009 (UTC)[reply]
274. Oppose – The main problem I have come across with autoformatting is that it is impossible to format ranges of dates within a month so that they display readably no matter what the preference is set to. Autoformatting just causes problems and has no advantages, it should be completely disabled. MTC (talk) 19:43, 11 April 2009 (UTC)[reply]
275. Oppose - Too much fuzz about something that adds negligible value to the users. GunnarHj (talk) 23:51, 11 April 2009 (UTC)[reply]
276. Oppose for many of the reasons stated above.
     talk) 01:32, 12 April 2009 (UTC)[reply
     ]
277. Oppose --Juliaaltagracia (talk) 06:47, 12 April 2009 (UTC)[reply]
278. Oppose We don't autoformat issues such as American/British usage, so why do this issue? 11 April 2009 and April 11, 2009 are both unambiguous, and as long as an article is internally consistant, there is no need for all of Wikipedia to be so. It would be exactly like autoformatting British users to read "colour" where American users type "color". It seems rather pointless. If the software could be modified to recognize and autoformat dates without any action from users (such as adding wikilinks or template headers or magic words or ANYTHING) that MAY be an OK idea. But the notion that editors should have to add square brackets or even worse, an entire template, to every date just so that we can pick whether we want the month name first or second seems beyond pointless. --Jayron32.talk.contribs 14:54, 12 April 2009 (UTC)[reply]
279. Oppose per above arguments. NSR77 ^T 15:52, 12 April 2009 (UTC)[reply]
280. Oppose What need is there for such a feature? This is not a rhetorical question; the answer is none. Unnecessary and trivial – basically per above. Andre666 (talk) 17:15, 12 April 2009 (UTC)[reply]
281. Oppose as per Scheinwerfermann (#233) and Waltham (#244). Also, the value of helping persnickety WP editors to see dates always in the format they're used to seeing them in does not outweigh the bother involved. No one is confused by dates, and editors need to be tolerant about style.
     talk) 18:20, 12 April 2009 (UTC)[reply
     ]
282. Oppose; too much effort for too little return. Make it truly automatic (no special formatting required) or forget it. --Spangineer^ws (háblame) 19:57, 12 April 2009 (UTC)[reply]
283. per all of the above arguments, and because a decision is needed. Hiding T 21:11, 12 April 2009 (UTC)[reply]
284. — Jake Wartenberg 23:49, 12 April 2009 (UTC)[reply]
285. (Disclosure - I was contacted privately to contribute after expressing an opinion last year, and would not have seen this discussion otherwise) - Oppose - What will the default format be? If it forces all articles into the same format, that will be bad - UK articles should default to UK format and USA articles should default to USA format. So the only way to make it work is to have two format statements (one for USA format, one for UK format) - and it's just not worth it for such a minor thing. Adds too much complexity to editing for no good reason.
     talk) 11:10, 13 April 2009 (UTC)[reply
     ]
286. Oppose. No benefit (and only grief) for the wiki. Moreover, the pro arguments are not convincing.

     #1 Proponents for date formatting allege that date-formatting is necessary to extract meta-data. That is false.

     • Meta-data has nothing whatsoever to do with date-formatting.
     • Meta-data is not a property of markup. If dates with markup have meta-data, and – as is implied – dates without markup do not have meta-data, then (it follows that) meta-data must be a property of markup. The implied ability to auto-generate meaningful content from markup would be, uh, pretty miraculous.
     • The meta-data instrinsic to dates has nothing to do with how how dates are written or formatted. Regardless of whether a date was formatted by hand, or with [[ ]], or {{#formatdate}}, the information that can be culled from that date will always remain the same. For example, that "12 April 2009" is a Sunday, that it is the 102nd day of the year, and so on.

     #2 Proponents for date formatting allege that "date markup has been identified" (?) "as central to the development of new features".

     • Those "features" have not been developed yet. We can't be expected to vote on vaporware.
     • Wikipedia is not a giant sandbox. If proponents want to develop new features, then they are welcome to do it elsewhere first, and then come back here for feedback.
     • Date-markup has existed for "almost six years now". Nothing whatsoever has been done with it in that time.

     #3 Proponents for date formatting presuppose that automation depends on dates being marked up. This is false.

     • It is not difficult to find all instances of a certain date. From those 80 million hits, of which only a minute fraction are marked up, it should be obvious that one does not need to markup a date to find references to it.
     • It is not at all difficult for software to "find" dates in text. Special markup is neither necessary nor desirable. Every reasonably-competent programmer can put together a routine to parse a text for dates. Such a routine is not significantly more complex than a routine that searches for any other combination of words.

     #4 Proponents have alleged that (server-side) "[d]ate autoformatting allows greater consistency". This is false.

     • Automated date formatting ala [[ ]] or {{#formatdate}} does not facilitate greater consistency than what can be accomplished if editors were to write out their dates by hand.
     • Articles have a whole gamut of consistency issues. Consistency is not just limited to date formatting style, but also includes citation style, ndash/mdash style, era style, and ENGVAR style.
       MOS has guidelines for all these issues, and there is no reason whatsoever why date formatting should warrant special treatment.
     • Editors are obliged to work cooperatively. This means that – before they begin editing an article – they also take the time to determine where the content that they wish to add should go. This means that they also honor the style already in use in an article. Not just citation style, dash style, era style, and ENGVAR style, etc, but date style as well.
     • It is not the task of servers to ensure consistency within articles. What server-side date-formatting automation does do is allow editors to disregard existing date-formatting conventions. Proponents for date markup sell this as an argument for "more choices". But what they really want is a license to say "what do I care what dateformat, engvar, era, citation style is in use? I'm going to use my preferred one, and the technology should sort it out!" Needless to say, that is outrageously inconsiderate, and – from a technical point of view – myopic.

     Summary: There is no "problem". Ergo, there is also nothing that requires a "solution". The original date-formatting solution (DateFormatter.php) was implemented to quell edit warring over date style. In the meanwhile we have gotten a fairly robust MOS guidelines for that and other style issues, and DateFormatter.php is no longer necessary. We don't need another hack to replace the first hack. We need editors to conform with MOS, which is a "site-wide standard" already in place. If anons/newbies fail to adhere to that "site-wide standard", then we can have a bot clean up after them. If established editors persistently refuse to adhere to that "site-wide standard", then we ought to community-block them (Arbcom decisions on style warring are a precendent). MOS rules, and the community doesn't need

     endless drama over non-problems. -- Fullstop (talk) 13:30, 13 April 2009 (UTC)[reply

     ]

287. Weak oppose. I originally voted 'support' because I think more customizability is generally better, and because the predominant "MMM DD, YYYY" date format feels like a case of American cultural standards being imposed on the rest of the world, and that makes me uncomfortable.
     talk) 14:33, 13 April 2009 (UTC)[reply
     ]

1. While I do not oppose the idea of autoformatting (provided that editors have an option to see dates as they are entered in the source, and provided that it uses a simple syntax—something like [{30 March 2008}] would be fine, {{#formatdate:|30 March 2008}} wouldn't), I oppose the current system, and oppose implementing any system on Wikipedia until it is shown to correctly handle date ranges, commas after year in M-Y-D, and so on. I also don't want it to start a slippery slope towards autoformatting of words and the like (at least until we implement an AI able to decide which meaning of "ass" is used when translating an article from American to Commonwealth English, that is). --A. di M. (talk) 06:18, 30 March 2009 (UTC)[reply]
2. I don't support the addition of metadata in this case. I just can't get worked up enough to call my "don't support" an "oppose." It's not really an issue, in my mind. Cnilep (talk) 14:28, 30 March 2009 (UTC)[reply]
3. While I see the advantage of autoformatting, I am aesthetically opposed to seeing link tags all over a page. Beyond that conflict between two lightly-held opinions, I really don't care about the issue. -- llywrch (talk) 16:22, 30 March 2009 (UTC)[reply]
4. Given how much heat vs. light this has attracted, I really don't care about the outcome, just that it gets settled, conclusively, one way or the other. Jclemens (talk) 16:26, 30 March 2009 (UTC)[reply]
5. It sounds useful, but we already have too much wikimarkup in our articles, to the point that an inexperienced user can't edit pages because of infoboxes and references. When the new GUI comes out next year, then it may be OK to add autoformatting. - Peregrine Fisher (talk) (contribs) 18:08, 30 March 2009 (UTC)[reply]
6. Tired of this stupid debate over dates. Lets get back to writing articles and improving the substance of the content. Aboutmovies (talk) 21:28, 30 March 2009 (UTC)[reply]
7. What, this still hasn't been resolved? Wait, that's no surprise. What this problem needs is someone proficient in PHP and very familiar with MediaWiki spending about a month working on code covering as many cases as possible, and then coming back and presenting their model + test cases. In the meantime, I could care less, and I have far better uses of my time than arguing over something so utterly trivial. 「ダイノガイ千？！」^{(Dinoguy1000)} 22:16, 30 March 2009 (UTC)[reply]
8. Link them, don't link them, how does that matter? I once found that I like the dates being in pretty blue links, but most of the time they don't really serve a purpose. Let's just be done with this discussion so that we can continue to write our articles without linking/delinking dates over and over again. -- クラウド６６８ 07:24, 31 March 2009 (UTC)[reply]
9. Much ado about nothing J04n(talk page) 01:13, 1 April 2009 (UTC)[reply]
10. Per A. di M. above. Ruslik (talk) 07:17, 1 April 2009 (UTC)[reply]
11. I actually like the idea of autoformatting and agree it is a good way forward (and yes i think it could eventually affect BC/BCE and other personal formatting tastes in order to create a more consistent and professional encyclopedia. the concerns about "too much work" are ridiculous - obviously there is somebody out there who would like to do this, a majority of dates are wrapped up in templates and those that aren't could be easily tagged with
    AWB, i've perfomed several similar edits applying {{convert}} to multiple articles with few errors which had more to do with my own shortcomings. however, it does not appear there is any demonstrated use of this and i would rather see it hacked out at wikilabs or somewhere else first before i agree to having this. - ΖαππερΝαππερ ^Babel_Alexandria 08:08, 1 April 2009 (UTC)[reply
    ]
12. Like the idea in principle, but the more templates we add to articles, the more wiki markup bloating the edit windows, the more intimidating even simple editing wikipedia becomes for newcomers. Professor marginalia (talk) 16:54, 1 April 2009 (UTC)[reply]
13. I'd don't mind either way whether dates have autoformatting options providing it doesn't rely on date linking. --Phil Holmes (talk) 08:21, 2 April 2009 (UTC)[reply]
14. I have no objection to allowing use of the {{#formatdate}} function, as long as it is not mandatory. Using it doesn't seem to do any harm, since unregistered users will see the same thing they would see if the date were not formatted at all, and registered users can use the preference setting if they wish. It also has the minor benefit (apparently, based on limited testing) of properly formatting at least some mis-formatted dates (like changing "April 2 2009" to "April 2, 2009"). Just don't go around berating editors who type in dates in plain text! --R'n'B (call me Russ) 13:26, 2 April 2009 (UTC)[reply]
15. Provided the date is specified as 7 March, 1997 or March 7, 1997 rather than 7-3-97 or 3-7-97 then there is no major problem. PRL42 (talk) 16:10, 2 April 2009 (UTC)[reply]
16. Voting Breeds Sock Puppets. — Preceding unsigned comment added by Gsonnenf (talk • contribs)
17. I am neutral in that ultimately I do not really care. However, I am leaning towards oppose because autoformatting is only useful to registered editors, not the general reader. Bendono (talk) 18:09, 3 April 2009 (UTC)[reply]
18. I am neutral because I see a balance of competing valid interests and can go along with whichever prevails. However I am strongly opposed to the notion in evidence in the subtext of many of the responses that elimination of date formatting eliminates the need for special markup for some dates. Used in narrow contexts such as with infoboxes, there is a family of templates whose only purpose currently is to emit microformat information. There have been a great deal of erroneous remarks that use the term metadata to associate this information with search and the like. Wikipedia also emits coordinate microformat data, and in the same way that it allows interaction with internet map applications, date/time templates allow interaction with internet applications that understand time data. With that said, I share the opinion of Professor marginalia and Peregrine Fisher expressed above and believe that edit text should not be needlessly cluttered with templates or other complicated markup. Even plain wikitext is a significant barrier and stands in the way of the core principle that everyone is an editor.-J JMesserly (talk) 16:37, 4 April 2009 (UTC)[reply]

    Neutral, per J JMesserly who makes excellent points just above. I don't really mind either way, but I agree that Wikipedia articles are getting too complicated when viewed in an edit box. Hiding T 14:02, 5 April 2009 (UTC)*Addendum. Just looked at the talk page and seen all the inane arguments over what consensus is. Please add my vote to whichever side gets the biggest pile in the hope it settles this once and for all and all parties accept it with good grace. Hiding T 10:14, 6 April 2009 (UTC)[reply]

19. My, my. Count me among the don't care crowd. I will never link another date again, regardless of the outcome of this debate. I've spent many tedious moments on WP linking dates for autoformatting at the demands of review processes within WP. I am sure if it ends up being policy, someone else will be happy to waste their time doing it. Me, not so much. Glad I got to opine though.--IvoShandor (talk) 06:24, 6 April 2009 (UTC)[reply]

    What I am saying is, as long as I don't have to do anything I don't care what we do. Thus, the neutral.--IvoShandor (talk) 13:20, 6 April 2009 (UTC)[reply]

20. Neutral - I barely understand how it works. Deb (talk) 18:05, 6 April 2009 (UTC)[reply]
21. Neutral - I find this a bit unnecessary (for myself to get involved in, ie.). prashanthns (talk) 06:00, 8 April 2009 (UTC)[reply]
22. As long as months are spelled out and not abbreviated as numbers (which autoformatting can't separate anyway), there is no real risk of confusion. At the same time, giving people display options is not a bad thing, so long as it does not place an undue burden on the site. Ham Pastrami (talk) 05:57, 10 April 2009 (UTC)[reply]
23. Most readers aren't going to be logged in so there isn't much point in going out of our way to get the dates to be autoformatted. However, a lot of people won't really notice the difference between 1 January 2009 and January 1 2009 and I don't mind if some pages use this syntax.
    (Talk) 10:37, 11 April 2009 (UTC)[reply
    ]
24. I tend to favor adopting ISO 8601 (yyyy-mm-dd) which could be autoformatted according to the user's preference. Though not widely used in prose (and recommended against, I believe) it's intuitive and easy to type. I oppose making the editor master a template just to write a date. I strongly oppose bluelinked dates, which are trivia. Thus, I'm not sure whether I should support or oppose autoformatting, as I'm not sure if my preference is on the table. Fletcher (talk) 14:21, 11 April 2009 (UTC)[reply]
25. In principle, I would tend to support autoformatting if it did not include autolinking (as it has heretofore) and the option is extended to all readers. Since this debate resurrected itself last summer, the two main reasons for deprecating datelinking have been the “sea of blue” and, more particularly, the fact that only a tiny percentage of readers – those who are registered users – even have the option of viewing dates in their preferred format; furthermore, the use of this option prevented registered users (who comprise a significant portion of the most active editors) from realizing what a mess the date formats in a given article are – which is what the great majority of readers actually see. There was always considerable support for a developer-created solution that would permit all readers to be able to set a preference; this would, of course, not remedy the mixed-format mess, but would at least allow readers to choose to not have to view these problems. To the extent that autoformatting of dates is not available to all readers, then it behooves editors to rely on the raw text format to know what may need cleaning up. The crux of the problem, then, is how resolvable the coding of such an autoformatting parser or template function is. Folk more knowledgeable than myself seem to be falling out on both sides of that issue, so until there’s a specific proposal on how to accomplish that, this whole poll is moot. Askari Mark (Talk) 00:50, 12 April 2009 (UTC)[reply]

Comments regarding autoformatting

• How much of a huge, bold, flashing editnotice would be enough to convince people that this section is about autoformatting, not linking? Or do we need an AbuseFilter warning on the word "link"? Anomie⚔ 00:12, 30 March 2009 (UTC)[reply]

• No-one above appears to have conflated the two. Ohconfucius (talk) 01:56, 30 March 2009 (UTC)[reply]

• A majority of the "oppose" !votes appear to have conflated the two. — Arthur Rubin (talk) 02:07, 30 March 2009 (UTC)[reply]

• To quote someone I know: "I wasn't going to reply unless an idiotic argument was presented by someone. Congratulations." Ohconfucius (talk) 03:21, 30 March 2009 (UTC)[reply]
• Wow. I am currently seeing 3 who mention linking in the rationale as if it was implied by autoformatting, but also give unrelated reasons (Awadewit, Bishonen, Bzuk), 3 who give no rationale (Donald Albury, Juliancolton, Chrishomingtang), and 29 who give a rationale that doesn't suggest they are confused about this. Since when is 3:29 a majority? Perhaps you are confused and think that this is about autoformatting without markup? Then read above under "What is date autoformatting?" It is not presented as an option. --Hans Adler (talk) 08:26, 30 March 2009 (UTC)[reply]

• otherlleft^{No, really, other way . . .} 03:38, 31 March 2009 (UTC)[reply
  ]
• And why must I give yet another rationale when so many have already been given. This is not something like AfD, where the weight of arguments invoking policy should be decisive, this is a preference poll. -- Donald Albury 12:34, 30 March 2009 (UTC)[reply]
• I've stated my opinion several times in the past, so I feel there's no need to provide a rationale. This is, as the title suggests, a poll. –Juliancolton | ^Talk 19:22, 30 March 2009 (UTC)[reply]
• Agree that this is a poll and tons of reasons have been given by others already.—
  t 20:24, 30 March 2009 (UTC)[reply
  ]

• Sorry, I meant no offence and no rationale is of course perfectly OK. The only problem is that in a situation where some editors give rationales that prove they are confused ("I hate autoformatting because I hate the sea of irrelevant blue links") with no clue how they would have voted if they were not, every vote without a rationale will potentially be discarded by those who don't like the result of the poll.

• Ah, ye of little (good) faith. -- Donald Albury 16:11, 31 March 2009 (UTC)[reply]

• talk · contribs), above, seems to have just mistaken the two as intertwined. —Locke Cole • t • c 13:19, 30 March 2009 (UTC)[reply
  ]

• I'm concerned about this too. If the proposal is defeated, so be it, but it would be a real shame if it were defeated because a large number of editors were still under a wrong impression of the implementation details.
  talk) 13:13, 30 March 2009 (UTC)[reply
  ]

• Why is it that so many people seem to think that marking up millions of dates requires a great deal of work, but removing markup from those dates is no work at all?-Jeff ^(talk) 01:09, 30 March 2009 (UTC)[reply]

• Bots can easily recognise and remove double-square brackets around dates. Adding date coding (especially complex coding) must be done contextually (instance-by-instance).
   HWV258  01:53, 30 March 2009 (UTC)[reply
  ]

Actually, I'd bet that a lot of the basic markup could be done by bots, if all they have to do is recognize dates and enclose them in something trivial. The actual choice of what format to use would need human intervention, but that could be separated from the markup around particular dates. — Gavia immer (talk) 02:53, 30 March 2009 (UTC)[reply]

Agreeing with the above. Bots should be able to easily recognize dates, marked up or not, through the use of regular expressions.-Jeff ^(talk) 03:13, 30 March 2009 (UTC)[reply]

(To the above two posts) The edit comment of "Most of the work could be bot-accomplished" is the key. How is most defined? Also, "The actual choice of what format to use would need human intervention" is a whopper in terms of slowing down the process. Anyhow, doesn't change the basic point that bot-removal of date formatting is trivial (to get back to the original post).

 HWV258  03:23, 30 March 2009 (UTC)[reply

]

If you separate the recognition of formattable dates from the format control, it's no big deal - just add a {{DEFAULTDATEFORMAT}} (or whatever name) parameter that works like {{DEFAULTSORT}}, appearing once per article to control the default date display format. Then you can add separate markup to actually set off dates, with an option to set the default display format for that one date. The sticky bit is that dates in direct quotations shouldn't be autoformatted, so a bot solution would have to recognize when to skip marking those up. A bot that got this even 90% right would leave very little work for human editors to slog through. — Gavia immer (talk) 04:20, 30 March 2009 (UTC)[reply]

With your response above, you've confirmed the validity of my initial response to the original question (you do remember the original question?). Please take this up on a talk page somewhere—we've been discussing these sort of issues for months now. Thanks.

 HWV258  06:10, 30 March 2009 (UTC)[reply

]

• I guess we need to add to the bold flashing editnotice that "unregistered users see inconsistent dates" can be easily fixed, so opposing on that basis is rather … misguided. And edit wars would occur just as often in the absence of a magic word with autoformatting, but they'd be worse because the warriors would be messing with dates all over the article (and possibly missing some each time). Anomie⚔ 02:48, 30 March 2009 (UTC)[reply]
  • Prevention of edit-warring? The notion I see raised above by one or two editors that autoformatting is needed to avoid edit-wars over which format is chosen for an article is, I believe, barking up the wrong tree. Yes, apparently the original system was a response to friction on this matter, but 2003 was early days for the community, and we had established proper rules for neither date formatting nor ENGVAR spelling. We now have well-established practices for both (MOSNUM, MoS), and they are highly successful, by all accounts. Tony (talk) 08:41, 30 March 2009 (UTC)[reply]
    • And yet still not as simple as letting editors enter dates in whatever format they like and letting the system auto format them to what readers prefer... at some point in the chain (editing/reading) you'll have someone using or seeing a date format they don't prefer when it needn't be that way. —Locke Cole • t • c 10:56, 30 March 2009 (UTC)[reply]
    • With regards to these "well-established practices" for date formatting, if they are really "highly successful", why has Wikipedia's Chief Technical Officer called for a rewrite of that guideline to use only one consistent format site-wide? --Ckatz^chat_spy 11:07, 30 March 2009 (UTC)[reply]
      • I am on record as wanting a mono-format for dates. Unfortunately, I am in the minority. It's not going to happen, because people believe WP:ENGVAR works, so we have to live with it. Having date-autoformatting could be likened to slicing off part of your feett to fit the new undersized shoes you just bought (in other words, don't make a mistake to compensate for a dumb move. Ohconfucius (talk) 13:51, 30 March 2009 (UTC)[reply]
    • Note that at the time of my comment above, there was only one person alluding to autoformatting as a solution for edit warring (and that in a vague, "it would have helped in this one case" way), while there was one "oppose" specifically claiming that autoformatting with a magic word for setting a default format for the article would directly lead to edit warring over the default format setting with the implication that there would not be such edit warring otherwise. I agree that autoformatting is not needed for edit war prevention; although it would likely prevent some would-be edit warriors from ignoring or fighting over how to apply
      WP:ENGVAR, I personally regard that as a side effect rather than a major driving reason. Anomie⚔ 12:05, 30 March 2009 (UTC)[reply
      ]

• (In response to Neutral #1 above) Would something along the lines of "{{d|30 March 2008}}" be simple enough? Keep in mind that the function "#formatdate" can easily be called from a template with a much simpler name. --Ckatz^chat_spy 06:26, 30 March 2009 (UTC)[reply]

  Considering the millions of times such a template would be called, that would be an enormous waste of server resources; but we could ask that the #formatdate function be renamed to #d, for example. --A. di M. (talk) 08:48, 30 March 2009 (UTC)[reply]

• Expansion on my rationale. One of the arguments for autoformatting is to "present a consistent date format". I think we should have consistency, but I don't believe autoformatting is the way forward. Personally, I would love for every article to use the fairly international style of day before month, but I fear that people like arguing about the pointless stuff too much for that to ever happen. Rambo's Revenge (How am I doing?) 13:36, 30 March 2009 (UTC)[reply]

• Isn't that an argument for auto formatting? Here we have a system that removes the need to argue (ever!) over which format to use, and it's a simple software solution. —Locke Cole • t • c 13:44, 30 March 2009 (UTC)[reply]

• No it is not. If IPs—the majority of Wikipedia readers—cannot choose their preference then autoformatting is not a good option. The only way to prevent IPs from getting a horrible mess of different formats is to choose what they see. If we do that, we might as well choose the style for everyone or completely standardise all dates into one format. Rambo's Revenge (How am I doing?) 14:23, 30 March 2009 (UTC)[reply]

• Part of the current proposal is that there would be a Wikipedia-wide default format setting (most likely DMY) for everyone who has not set a preference, including IP users, and a magic word so a particular article can change the default (i.e. to MDY) when that is appropriate per
  in good faith understand why opposers keep claiming IP users will see some sort of mish-mash. I also find a claim that every IP user has to be able to set a date preference spurious, as we have an easy way for anyone to set any preference: register an account. Anomie⚔ 15:05, 30 March 2009 (UTC)[reply
  ]

• But the point you are missing is that in order to maintain consistency for all users, every date on a page needs to be coded (in order to be rendered properly based on various preferences). The problem with "every date" is that it is extremely difficult to define rules needed in order to detect all the different types of date formats found on WP. Date ranges and slashed-dates are just two examples, but also difficult is to precisely detect the comma in US date formats. These issues remain unaddressed—after months of debate, and lots of examples demonstrating the problems can easily be found. Many people voting "support" are unaware of the technical issues involved. (Incidentally, I don't blame them so much as these issues are not easily grasped by people who have not been involved with the debate for some time.)
   HWV258  00:46, 31 March 2009 (UTC)[reply
  ]

• Hi, I'm a computer programmer. Are you? The reason I ask is that you assert that "it is extremely difficult to define rules needed in order to detect all the different types of date formats found on WP", which strikes me as a statement that would be made by someone who doesn't actually know what they're talking about. There is no real "detecting" necessary; someone just needs to come up with a syntax for specifying date ranges, slashed dates, trailing commas, and the like. For example, {{#formatdate:1 January 2009/2 January 2009}} could be the format for a slashed date, and output as "1/2 January 2009", "January 1/2, 2009", and so on based on the active format; {{#formatdate:1 January 2009–10 January 2009}} or {{#formatdate:1 January 2009|10 January 2009}} could be the format for entering a date range, and output appropriately (there could even be a preference for "1 January 2009 – 10 January 2009" versus "1–10 January 2009" style output, if people wanted it). With a little more effort, any of the (unambiguous) output formats could also be accepted as input. The need for the trailing commas could easily enough be specified as {{#formatdate:1 January 2009|,}} or {{#formatdate:January 1, 2009,}}. Something else that I personally would like to see is a "{{#formattabulardate}}" function, so people who would prefer to see dates in tables and lists as 2009-01-01 versus 1 Jan 2009 versus the full 1 January 2009 could set a preference for that. It's not particularly hard to do any of that, but why should someone bother when the discussion is full of people (not necessarily you, don't take this personally) who will oppose everything without end, drowning out any other discussion, to the point of
  WP:POINT? Anomie⚔ 12:26, 31 March 2009 (UTC)[reply
  ]

• Actually, I am a programmer (and your question indicates to everyone that you haven't been following the debate over the previous few months). I was the only one who actively push to get a specification for auto-formatting established (
   HWV258  23:19, 31 March 2009 (UTC)[reply
  ]

• Of course I haven't followed the debate, certain people have made the situation akin to diving for pearls in a cesspool. I don't understand how you can claim it's so difficult for code to solve the problems you raised in your paragraph above, though, since you state that you are familiar with programming. I also don't see any particular problem with List of compositions by George Frideric Handel; sure, it might need a bit of human attention to get everything marked up, but I see nothing in there that would cause any trouble for a well-written formatter; or is the whole of your concern there that someone would have to do a little bit of formatting work? As for those "who will oppose everything without end", either we're talking about different people or our views are so opposed that we will never reach an agreement on the matter. Anomie⚔ 02:10, 1 April 2009 (UTC)[reply]

• I didnt' claim "it's so difficult for code to solve the problems"—rather it is looking increasingly likely that it is impossible to specify the problem in the first place.
   HWV258  04:18, 1 April 2009 (UTC)[reply
  ]

• How is it impossible to specify what the a bot would do? The bot would find plain dates, pre-existing or entered by new users, and convert them to a standard form inside an autoformat bracket. Regular expressions already exist for finding dates in widely used forms. If the date was ambiguous, such as 07-03-02, it could inform wikignomes via wiki: page or any other method, who could manually fix it, helping in the already existing task of removing ambiguity from Wikipedia. The scope of the bot and implementation seem completely clear, maybe 5 hours coding tops on an existing framework.Gsonnenf (talk)

I think the bot would have to be quite conservative. Spend an hour or so trying to devise a syntax for date formats. After doing so, how to work out ambiguous dates— or at least discover that they are ambiguous and mark them so. Then partial dates such as "April 2009" or "2009". (oh, whoops, it 2,009 kilometres (1,248 mi)). Then quoted dates which must be left alone. Then perhaps the French Revolutionary Calendar. It is *not* trivial. I am in support but I think it is best left to human markup rather than a bot. For sure, have a bot gather the info after it's been marked up, I'm all for that. But not guess what is, or is not, a date. SimonTrew (talk) 03:41, 8 April 2009 (UTC)[reply]

I agree the bot would need to be conservative. As I understand it partial dates aren't used with date autoformat, please correct me if I'm wrong. When you say "Spend an hour or so trying to devise a syntax for date formats." do you mean thinking of how to have the parser recognize them? If so, this problem has already has a published solution. Nested quotation recognition is also a solved parser problem. The logic code for determining ambiguity of format in recognized dates is simple as a couple if/then/and statements. This still looks like a simple task, I'm uncertain as to what you mean by "trivial" as it has different meanings in different science fields. I could see how a new coder or one without exposure to modern parsing libraries or parsing exposure may see this problem as complex. With proper knowledge, which I'm sure many coders on Wikipedia have, the solution is simple to implement. I would prefer conservative date changes by bots with human confirmation. This would ease the burden and time constraint on humans. Manually verifying a date on a page would probably take 5-10 seconds, where in going through the sequence of changing them could take about 5 to 10 times as long (depending on server conditions).Gsonnenf (talk)

• "How is it impossible to specify what the a bot would do?"—this is wandering from the original point (i.e. I didn't mention bots). Please re-read my points.
   HWV258  02:00, 9 April 2009 (UTC)[reply
  ]

• I re-read your points and find them moot. The vast majority of date forms can be easily recognized. I disagree with your statement that "every date on a page needs to be coded". Date forms that are intentionally abiguious or not well formed (e.g. year 197x ) should either be clarified manually or left alone. Autoformatting would only need to be applied to well formed dates. Any date that can be recognized unambiguously, (jan 16, 1973, 10/22/1001) could be easily recognized by both humans and parsers. So in this case it is not longer "extremely difficult to define rules needed in order to detect all the different types". The comment "Date ranges and slashed-dates are just two examples, but also difficult is to precisely detect the comma in US date formats" is not correct, these can be easily identified using a parser and regular expressions. The above comment is also very suggestive of a bot, which contradicts your statement "I didn't mention bots". Unless of course you meant that humans would have a hard time "detecting the comma in US date formats", which is complete nonsense. So as it turns out my above argument does not wander from the original point. Unless of course you wandered from the original point in your above statements. If that is the case, please present your original point and present an argument that does not "wander from the original point".Gsonnenf (talk)

• "I disagree with your statement that "every date on a page needs to be coded"" leads me to believe that we are talking about different things (and your disagreement probably indicates you have not been following the debate over the previous number of months). The point about coding all dates is that it is impossible to guarantee date rendering consistency in an article that contains at least one coded date—but with not all dates being coded in the article. It has been clearly understood by all that you either code all dates in an article, or you code none. If you are suggesting that coding isn't necessary because a page pre-processor can parse (and reformat) all dates in real time—then you are probably the first to do so. These current RfCs are not to do with bot activity (that debate will come after these RfCs are complete).
   HWV258  00:16, 12 April 2009 (UTC)[reply
  ]

• The IPs would not get a bunch of different styles since the feature would provide a standard default for them. Also, developers have mentioned using Javascript to allow IPs to set a preference, though no developer has yet worked on that solution.—Ost (talk) 15:06, 30 March 2009 (UTC)[reply]

• *sigh* If you actually read my last post I never claimed IPs will get a mish-mash of styles. I said that the only way to prevent them getting that is to choose their preference for them. I then said that there is no point in choosing a standard style for them, because it would need to be agreed upon. If we can agree a choice for that, we should just implement that choice as the date style across Wikipedia without autoformatting, because that would give real consistency. I am well aware of what is going on and am not fond of other users trying to twist my words towards their !vote. Rambo's Revenge (How am I doing?) 16:55, 30 March 2009 (UTC)[reply]

• You have presented a
  WP:ENGVAR on this issue". Anomie⚔ 22:19, 30 March 2009 (UTC)[reply
  ]

• (In response to Oppose#89 above) FYI, we are discussing that; the recent changes to the system now allow autoformatting to apply a default format for unregistered users, and there is a patch in the works (I'll try to get the Bugzilla link ASAP) that would add the "per-page" option you've mentioned. --Ckatz^chat_spy 21:26, 30 March 2009 (UTC)[reply]

  Um ... no, Josiah is talking about autoformatting in the sense of allowing a few privileged editors to select a month-day or day-month order. A consistent fixed-text format for IP users is the reality in the thousands of article that have dispensed with autoformatting. Tony (talk) 08:23, 31 March 2009 (UTC)[reply]

  Actually, you're both right. I oppose autoformatting as it currently exists, as a special option for a few editors. However, I would support autoformatting as something that could be applied universally with appropriate regional variations. For example, if a citation using the ugly 2009-04-05 format were used in two articles, one dealing with a US-based subject and the other dealing with a UK-based subject, it would appear (to all readers) in the US-based article as April 5, 2009 and in the UK-based article as 5 April 2009. I'd support an autoformatting system that automatically translated dates in that fashion, as long as there was a parameter that allowed for articles to use appropriate formats, in keeping with

  WP:MOSDATE. In other words, I'd support autoformatting as a method for producing consistency within articles, but I oppose autoformatting as a way to enforce consistency throughout the encyclopedia, or as a way to make dates appear consistent to a small minority of readers. —Josiah Rowe (talk • contribs) 06:06, 5 April 2009 (UTC)[reply

  ]

• I'm in favor of the idea of autoformatting, but against the requirements it will make on editor and hardware. Debresser (talk) 16:50, 30 March 2009 (UTC)[reply]

I'm with you. I think the server should do all the work, recognizing dates for what they are and regurgitating them for viewers to match their preferences. Editors should only have to make sure that dates are consistent throughout the article. I'm against using some kind of template or marker or formatting. Binksternet (talk) 06:01, 3 April 2009 (UTC)[reply]

That is impossible: It would result in changing of dates in exact quotes which contained dates by default. You should never change an exact quote, but no software is clever enough to unambiguously spot a quote, even if put in by a newbie that formats it in a slightly unexpected way. Creating a way to bypass this is not a solution, because the mechanism to do so is going to be obscure, and most editors won't know it. It ruins usablity for editors, in order to allow a tiny minority of people to select which of two date formats they like. Shoemaker's Holiday (talk) 06:57, 5 April 2009 (UTC)[reply]

• At the present time (61 support, 91 oppose), support #42 and Oppose #3, #12, #13, #22, #42, and #73 think that it's talking about linking. A number of further comments seem think it's talking about things looking different for editors and IPs; which is (1) always true that editors can adjust viewing format, using gadgets, preferences, and Javascript; and is not necessarily true of autoformatting. — Arthur Rubin (talk) 00:09, 31 March 2009 (UTC)[reply]

why are you interpreting Oppose #3 and #73 as "think[ing] that it's talking about linking"? i agree that there are a couple of !voters who appear to be confusing the two issues and a couple of "hanging chad !votes", but both Oppose #3 and Oppose #73 appear cognizant that linking and autoformatting are two different issues.

either way it's not a high rate of confusion - that's good! and the "hanging chad !voters" still have time to clarify their views if they care to.

meanwhile, it's right that some !voters are saying they don't want logged-in editors to see different content than unlogged-in users. you disagree with that viewpoint, but that doesn't mean their !votes "don't count".

Sssoul (talk) 07:21, 31 March 2009 (UTC)[reply

]

Sorry; either I made a mistake; they changed their !votes, or the !votes got renumbered. Still, the purpose of this poll is to find

WP:CONSENSUS, and I don't see even a clear supermajority for oppose (yet). As not wanting logged-in editors to see different content than unlogged in users, one might argue that it's a reason contrary to policy as defined by the developers. We would need to remove the gadgets and javascript customization. I'll post more on the talk page. — Arthur Rubin (talk) 16:06, 1 April 2009 (UTC)[reply

]

• The "only for editors" claim has been bandied about throughout this debate over the past year, simply because it is an easy rallying cry for the three or four core editors who are really pushing the "delink" campaign. Thing is, there's never been any proof for the numeric claims (despite repeated requests), and never any acknowledgement of the readers who may have registered an account not to edit, but in order to access features such as date formatting, watchlists, and gadgets. (The "only for editors" mantra also fails to mention that IPs can't access any special perks, not just autoformatting.) --Ckatz^chat_spy 02:24, 31 March 2009 (UTC)[reply]

Good grief! how hard can it be?. The whole formatting thing is a no-brainer. Simple fact is, if functionality is provided for autoformatting it can be provided to most IP users too with simple preferences option for them via cookie system or countless other ways. Search engines, most news sources and millions of commercial sites have been doing it since Jesus was a small boy. Come down to it, autoformatting also allows the potential to do away with the linking argument completely because it can be controlled by a users preferences as well. Want to link dates? switch it on via preferences. don't want them linked? leave it off. And don't bore me with the non-logged in users rubbish - most of them a: don't care, b: have cookies turned on (or are unaware of their presence) or c: know how to allow for cookies by site. BOTs to do the bulk conversions to simple syntax (say YYYY-MM-DD or #dYYYY-MM-DD) and wikignomes will make short work of the rest. Default presentation for those who haven't set it (maybe with a bit of fancy footwork detecting where they are accessing from to feed them American or ISO format by default). Doing something is unlikely to make it more inconsistent than it currently is.--ClubOranje^T 08:08, 3 April 2009 (UTC)[reply]

• Has anyone thought of having a bot do autoformatting? That would nearly neutralize editor requirements, just invest some effort in the bot, and sit back and watch! Oldlaptop321 (talk) 23:58, 6 April 2009 (UTC)[reply]

I think it is accepted on all sides that there will be bots and templates to assist (and hopefully not to destroy). If it is relatively relaxed and gets it right most of the time, like Template:Coord or Template:Convert, I don't see it being a big problem. But like those, you don't *have* to use them, hence my support; they are nice things to have. In a way I can't see why this even goes to a vote since I can't think of much of a reason, beyond finding user preferences, why this can't all be done in a template. SimonTrew (talk) 01:46, 7 April 2009 (UTC)[reply]

Actually now I am wondering whether this is in the purvue of Template:Convert. A date is only a measure after all, and its means of expression is its unit of measure. That's probably outside the scope of this vote, though. It's an interesting question to ask those in the "Oppose" camp; do you want to get rid of Template:Convert, even if you don't use it on every single measure you write? SimonTrew (talk) 01:50, 7 April 2009 (UTC)[reply]

SimonTrew, this hasn't gone to a vote. We

don't vote here. See the "!vote" terminology people are using? That's why. Also, I don't agree with your comparison of this present issue to Template:convert. The similarities are superficial and few, as it seems to me. —Scheinwerfermann ^T·_C02:32, 7 April 2009 (UTC)[reply

]

The similarities are superficial and few precisely because time is just another dimension that can be relatively easily incorporated into the Convert template, or if not, another template can be made analagous to it. And I have worked designing and implementing very complicated units of measure conversion systems, and I know they are not easy. SimonTrew (talk) 02:51, 7 April 2009 (UTC)[reply]

All Support entries that are founded on reader choice should be disregarded when finalizing the findings of this RfC. What reader choice? The reader gets the site default, or the contributing editor's choice. Remember that registered users = subset of editors, and in turn editors are a tiny subset of readers. All Support users who clamor that the reader need only edit a setting should be deliberateley ignored by the rest of the community for a period no shorter than the time it takes defeat any and all proposals in support for auto-formatting. --Karbinski (talk) 21:38, 9 April 2009 (UTC)[reply]

Sorry, but that's not valid. There is no requirement that you must edit if you register; anyone - anyone - can register an account, and if they choose to use that account to read only, so be it. Accounts can be useful to readers who wish to use the gadgets, the watchlist, different skins, and so on. --Ckatz^chat_spy 21:49, 9 April 2009 (UTC)[reply]

Sorry about that, but if we leave out the middle, it is correct: Remember registered users are a tiny subset of readers. Not that it has bearing, but registered users are also a subset of editors. Karbinski (talk) 21:57, 9 April 2009 (UTC)[reply]

Many of the contra arguments speak to the issue that most readers are anons. I know from experience that people assume the only reason to register for an account is to make edits. If there were tangible benefits (like getting standardized dates, watchlists, and so on) and those benefits were promoted to readers, we might get more editors. And once they have an account, they might be more obliged to make an occasional edit. And that could lead to editing as a hobby, until they are fully assimilated into the collective. (Oops! Been watching too much Star Trek perhaps?). The point is, anything that is good for editors is ultimately good for the readers, too. --Willscrlt (→“¡¿Talk?!”) 14:14, 13 April 2009 (UTC)[reply]

Responses

• Several users have indicated that autoformatting is the only way to achieve consistency through in one article, and this is simply not true. EDIT: This may be true for for achieving site-wide consistency, but that begs the question of why the way the dates look is such a big deal. We can all look at DMY or MDY or even YMD (2000 January 1) and fairly easily determine what the date is.
• User:This flag once was red
  , using the ambiguous 3/2/03 type format is not an option anyway.

• I think you've misunderstood me (or I've not been clear) - my thinking is that by using a template for dates it will discourage the entry of dates as DD/MM or MM/YY, not that dates will no longer be displayed as DD/MM or MM/YY. I agree that this problem isn't going to go away completely, but it should be alleviated as editors get into the habit of specifying dates in terms of {{... day=2|month=3| ...}}, instead of just typing "2/3/09" and hoping that whoever cleans up after them magically knows whether the date is DD/MM or MM/DD. Cheers,
  propaganda_deeds 12:53, 31 March 2009 (UTC)[reply
  ]

• "Before autoformatting was introduced, there were lengthy rows about how to format dates. This seems recently to have come back, just as some started delinking dates." from docu (talk · contribs); can someone point me to these length rows on date formatting? I haven't seen any. Not referring to linking here.
• "Also, autoformatting helps prevent edit warring" A an over-used argument with little evidence provided. Actually, these edit wars are few and far between.
• To the users who cited metadata as a reason for needing autoformatting, can someone provide examples of how this metadata could be used? Dabomb87 (talk) 02:16, 31 March 2009 (UTC)[reply]

Other than imposing a site-wide single format, as the developers have suggested, how do you propose to ensure all articles are consistent with one another? Either we go to a single standard, or we persist with the first-past-the-post "this is American no it's international" methodology. If the latter is the case, it is only prudent to provide some method of presenting a uniform, consistent look. --Ckatz^chat_spy 02:28, 31 March 2009 (UTC)[reply]

Sorry, I'll be more clear. I edited my above post. Dabomb87 (talk) 12:47, 31 March 2009 (UTC)[reply]

Most of the arguments against autoformatting seem to boil down to "this would be a lot of work, and there is no advantage in it for me". I fail to see how this is an argument for forbidding those who do care about consistency from doing the work. Why does this have to be framed in terms of either "everybody must use this markup" or "nobody is allowed to use this markup"? That's not the wiki way. The wiki tradition would be to encourage people to contribute even if they can't be bothered to use the more complex markups, and then let others insert advanced markup if they care to.

What active harm do all of you opposers suffer because someone else adds autoformatting? It won't require you to lift a finger either way. –Henning Makholm (talk) 11:20, 31 March 2009 (UTC)[reply]

This is an important point. Why cant autoformatting be implemented and later have a discussion about whether the MOS should encourage its use? The first section to this poll should have been left until after implementation when users can see what it actually involves. I seem to remember that {{cite...}} came about this way, and is probably more difficult for unregistered users to edit and breaks up the text far more than this proposal. |→

GMT

)

Yes but {{cite...}} provides an important - one might even say essential - feature for an encyclopedia. This more than justifies the cost in terms of difficulty of use and so on that the markup introduces. Date autoformatting on the other hand provides at best an extremely minor cosmetic tweak. Most people don't care what formats their dates are written in. They will even use a variety of formats in their own writing or speech without a second thought. The number of people who are actually annoyed by reading a date in a format they don't like must be extraordinarily small. These pedants are considerably outnumbered by those like myself who find needlessly complicated markup annoying, or who are annoyed by the excessive linking and sometimes anomalous results created by poorly implemented date autoformatting. Hawthorn (talk) 23:38, 31 March 2009 (UTC)[reply]

The number of people who are actually annoyed by other editors inserting date markeup must be even extraordinarily smaller. Even if you yourself find it annoying to enter such markup, I don't see how it can conceivably annoy you to let other people do it. Nobody is proposing to say that you should enter the formatting yourself if you don't feel like it, but how can it possibly disturb you if other people do so? Again, the proposal is about NON-LINKING autoformatting, so there will be no excessive linking to annoy you. –Henning Makholm (talk) 14:35, 1 April 2009 (UTC)[reply]

Henning Makholm seems to be overlooking the fact that anyone who wants to edit an article has to deal with the markup other people have inserted - even if "deal with it" only means "figure out how to edit 'around' it". it can be extremely daunting. many people are saying that date-format preferences are not important enough to justify even the double-bracket markup it now uses, let alone adding even more markup (a la {{formatdate|12 December 1981}} to every date in the encyclopedia.)

Sssoul (talk) 07:08, 2 April 2009 (UTC)[reply

]

Once the formatting is there, it is not daunting at all. On the contrary, it is extremely self-documenting how the markup you quote works, and I cannot imagine anybody using more than a quarter second thinking "hm, it says formatdate, wonder what that means ... ah, flash of brilliance, it probably is something about formatting the date that comes after.". Now, I can understand not wanting to go around remembering how the markup works, and thus not wanting to enter it from scratch, but really, anybody who have trouble noticing and editing around a markup as clear and unambiguous as the one you show probably wouldn't be able to stitch together a coherent sentence for the encyclopedia in plain prose.

The double-bracketing is annoying because it creates needless bluelinks in the output that are hardly ever relevant in context. That is annoying. But a small bit of really, easily, self-documenting markup to make live easier for the (perhaps few) people who care about it? Not at all. –Henning Makholm (talk) 11:32, 2 April 2009 (UTC)[reply]

okay, so you don't find it daunting or annoying to have to wade through markup that you perceive as unnecessary; other people do find it daunting and/or annoying. it's one of those "different opinion" things, and saying "no it isn't" doesn't change that. peace

Sssoul (talk) 07:37, 3 April 2009 (UTC)[reply

]

It's no worry at all to me, as I am from a country (the UK) where both formats are used interchangeably. If you reread my post above (oppose 138) you'll see that

Phil Bridger (talk) 00:24, 1 April 2009 (UTC)[reply

]

I'm not sure if I'm following any more (my confusion above started with the word "there" in "so why not just follow the standard that is used exclusively in civilian life there"—where is "there"?). Are you suggesting that the

 HWV258  01:04, 1 April 2009 (UTC)[reply

]

Sorry if I was unclear, by the word "there" I meant the United States. And once again, what is radical about using MMM DD, YYYY for the

Phil Bridger (talk) 08:54, 1 April 2009 (UTC)[reply

]

It's simply not true that they are used interchangeably. If you ever have to fill a form in the UK, it's quite possible that you have to enter a date into fields that look like this, __/__/____. In my experience they will always expect you to use DMY format, even though in some cases they may not mention it because it really goes without saying. This is because DMY format is much more common in general, including when the month is spelled out. --Hans Adler (talk) 15:13, 1 April 2009 (UTC)[reply]

In forms the date is usually entered in all numeric format, so there obviously has to be a standard, and, yes, that standard is different in the UK and the US, but in other contexts where the month is spelt out both formats are common. Do you seriously think that people have difficulty understanding the date, or get any sense that there's something wrong with it, when thay read it in

Phil Bridger (talk) 15:45, 1 April 2009 (UTC)[reply

]

Sorry for absurdly lecturing you without seeing that you are actually from the UK. I agree that standardising on MDY would be an option. However, this is very similar to standardising on Oxford style "ize" spellings for verbs in British English, and it seems that we haven't adopted this either. Therefore it seems unlikely that your argument will convince many in this poll. I think it should really be discussed separately. --Hans Adler (talk) 16:05, 1 April 2009 (UTC)[reply]

I'd just like to concur with this point - whenever I see this debate crop up, I honestly find it hard to remember which variant I'm supposed to prefer, or which one I'm supposed to object to. Written numerically, there's a standard, but written textually then "1st February" or "February 1st" are pretty much interchangeable to a British reader, and I'll often use the two in the same piece of writing, or use one one day and the other the next.

talk | 15:29, 3 April 2009 (UTC)[reply

]

A few of the above UK newspaper examples don't use American date format consistently when digging into the news articles. While the top banner of The Sun may show MDY, DMY-based content such as "Published: 04 Apr 2009" appear in articles before the current date [16]; here's a "13th April 2009" from The Daily Star, and another 13th April from The Daily Mail. Such commercial websites may not be reliable indicators for date format anyway as these can sometimes be skewed by software defaults, often biased towards US usage.

Government standards and practice would seem more reliable to consider for this discussion. UK government usage consistently uses DMY and rejects US/MDY format. There are moot differences as to whether ordinal letters (12th vs 12) are used on day numbers, but there is no interchangeability of ordering on official UK levels e.g. TDA, Cabinet Office, Hants, Mansfield District Council.

Furthermore, DMY is generally used by international bodies such as the

OECD [18], ITU [19], ICRC [20]. That's compelling evidence of what date format is considered the norm on an international scale and where a global project such as WP should be headed. But if we can't get there in the short term, we should make good use of the autoformatting capability (already developed for the most part) for the benefit of the various audiences. Dl2000 (talk) 16:41, 13 April 2009 (UTC)[reply

]