Requests for comment/Technical agreement on dates and times

The following request for comments is closed. After 3 months of discussion, minimal participation and no consensus. This is also not something that can likely be solved with a global policy/consensus change, as individual local enforcement of time standards would be next to impossible. Vermont 🐿️ (talk) 02:41, 28 August 2022 (UTC)[reply]

Hello! It happened a couple of years ago when we were thinking about the T132308 solution. The problem arose that Citoid suddenly began to insert dates that templates and MediaWiki did not support Then, although this (perhaps) was a logical solution.

And I thought, dates are one of the most common variables in our projects. They are transferred from project to project, Wikidata is filled with them, a huge number of tools work with them. But we do not have a standard for all projects that we can recommend to users and developers for working with dates in technical terms. Templates in many projects do not support ISO 8601, they are filled in through parameters or in general in the project language, which does not allow you to comfortably transfer or translate information.

My suggestion is as follows:

Adopt either ISO 8601 (closed standard?) or EDTF (open standard?) or IETF (thanks @putnik) as a technical standard.
Write an agreement that in technical spaces, when dates using, it is recommended to use this format.
It is recommended to substitute dates in templates in this format, and already through templates to convert them into a human-readable form (either through MediaWiki, or local modules, for example, Module:Calendar). If we accept EDTF, we will need to update the MediaWiki #time parser - T280510.
Tell about it in projects, in a technical mailing list.

At one time, we adopted a similar agreement for Wikipedia in Russian — Wikipedia:Technical agreement on dates and times, it became more convenient and clearer how to fill in the templates and what to focus on. Iniquity (talk) 11:54, 30 May 2022 (UTC)[reply]

Oppose There's absolutely no need to set a global policy on this. * Pppery * _{it has begun} 20:29, 30 May 2022 (UTC)[reply]
@Pppery, hi, do you often transfer materials from one project to another? Tell us about your practice, please. How do you display service dates in different languages? Iniquity (talk) 20:58, 30 May 2022 (UTC)[reply]
Oppose as hopeless. It would be better to develop a robust set of date-translation tools. Jonesey95 (talk) 21:29, 30 May 2022 (UTC)[reply]
@Jonesey95, I gave several tools in the description (both the module and the extension). But in any case, in order to carry out conversion operations, they must go through some kind of standard. Iniquity (talk) 21:31, 30 May 2022 (UTC)[reply]
Am I the first user Support this? It looks like for some political issues around Kyiv, current time format may be unfair. Moreover and even no considerations on political, there should have a way to allow self designation of it rather than forcing on PHP's skybook. --Liuxinyu970226 (talk) 05:40, 31 May 2022 (UTC)[reply]
Oppose because each of the suggested standards is not suitable. ISO 8601 is closed and history in Wikipedia and Wikidata shows that most editors and developers will not posses the expensive standard, and thus will make errors in using it because they don't know what it says. EDTF went over to the dark side and became the main source of input for the latest version of ISO 8601, so EDTF is essentially abandoned in favor of the expensive closed standard.

"Date and Time on the Internet: Timestamps with additional information" disqualifies itself by stating "this document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time." UTC began on 1 January 1960 (Dennis McCarthy & P. Kenneth Seidelmann, TIME From Earth Rotation to Atomic Physics, n.p.: WILEY-VCH, 2009, p. 16.) The choice of UTC not only makes it technically unsuitable for the Wikimedia Foundation because of the presence of historical information; it shows the author(s) are only interested in current events and it is probable the standard contains restrictions that make it unfit for historical information. Even if no such restrictions are present yet, it appears the development crowd does not care about historical information and if it is ever developed, it is likely to go in a direction that does not suit Wikimedia Foundation. Jc3s5h (talk) 12:46, 31 May 2022 (UTC)[reply]

@Jc3s5h, this discussion is fundamentally about the |date= parameter in citation templates. In practice, do you expect to be citing any sources for which the fine details of ISO 8601 will change what you want to see in that field? I don't expect proleptic Gregorian calendar calculations to be relevant for publication dates, and I've only rarely seen a down-to-the-minute timestamp in a publication.

The most salient dispute is about how to represent a publication date for a monthly periodical in wikitext. This is not how to display the date to readers, but specifically and solely how to represent it in wikitext. This affects people who write templates and people who translate articles. For example, do you prefer:

|date=May 2022 – extra manual work for all translators (more than a million articles have been translated, so this is not a trivial consideration)
|date=2022-05 – a small fraction of possible combinations (all involving publications in the years '01 through '11) could be a two-year range that (a) could be used for the rare biennial publication and (b) has been disallowed as a year–month representation since sometime around '06 by enwiki's MOS. (The then-current sources were particularly likely to have this problem: does 2006-07 mean July 2006, a the two years from 2006 to 2007, or is it a typo? Before then, the enwiki MOS said only "Do not use numbers to express a month, except in full ISO 8601 format, which always includes the year", and the main concern was linking all the dates so that the dates chosen in editors' prefs would display in their preferred format.)
|date=2022-05-XX – might be technically wrong per ISO 8601 for some publications; would satisfy enwiki's MOS (which doesn't mention it); would definitely require ruwiki and others to re-write their citation templates

In terms of what readers see, either of the latter two can be 'translated' locally by the citation templates to display whatever you want. The current system is the middle one. Whatamidoing (WMF) (talk) 18:14, 31 May 2022 (UTC)[reply]

The initial post does not clearly define the scope of this proposal, and projects tend to expand beyond their original scope. For example, the desire to automate translation of citations was probably not envisioned when citation templates were first created. As best I can tell, the scope of this proposal would be citations to materials on the internet, which can be accessed through a URL, DOI, ISSN, or similar, if and only if the citation is generated by Citoid.

It is customary to cite the original publication date when reliable scans of paper documents are available on the internet. For example, if I were going to cite the article "2d Cycle of 400 Years Begins for the Gregorian Calendar" which appeared in the The New York Times, written by Tom Ferrel, and appeared in Section A, page 16, I would cite the date as October 15, 1982, despite the fact that I did not read the printed paper, I read the online archive. Citoid agrees when I enter the URL of the article in the archive. So the argument that potential confusion only exists for years in the range 2001 through 2011 is not true.

The Julian calendar was in use in some countries until 1923, so citing publications with Julian calendar dates with a specific day or month, while not terribly common, does occur.

Also, it would be wrong to think the issue is letting Citoid generate a weird date format, and then having the citation templates render the weird format in a normal format. Whatever format Citoid produces will be in the wikitext, and read by editors who use the source editor. These editors will then imitate what they see in manually composed citations, and probably outside of citations as well. So I believe dates should be proper dates that are acceptable in English writing (or whichever Wikipedia we're considering). Jc3s5h (talk) 22:13, 31 May 2022 (UTC)[reply]

I do not understand your comment about potential confusion only existing for '01 through '11 (of any century, by the way: 1901-02 is exactly as ambiguous as 2001-02, and neither 1901-01 nor 2001-01 are ambiguous). AFAICT there are no circumstances under which 1982-10 (the ISO 8601 standard for October 1982) could be used as a date in a citation to mean from 1982 until 2010 and comply with w:en:MOS:DATERANGE. It is (a) not "two consecutive years", (b) not in an infobox or table, and (c) there is no established convention for using this. If it doesn't fit those three exceptions, then MOS:DATERANGE says that YYYY-YY is not acceptable.

The disputed format is not 1982-10-15; it is the equivalent for monthly publications, including most scholarly journals. Try putting doi: 10.1080/01621459.1982.10477841 into citoid and see what happens with the date. Whatamidoing (WMF) (talk) 02:33, 1 June 2022 (UTC)[reply]

Support ISO 8601 YYYY-MM-DD HH:MM:SS. No 8/11/3 dates anymore please. Taylor 49 (talk) 22:06, 30 June 2022 (UTC)[reply]
Support standards such as ISO 8601 were designed exactly for this purpose. Adopting ISO 8601 seems like a no-brainer to me. Jc3s5h, you are correct that the ISO standard descriptions are closed and expensive, but its essence is well summarised in a Wikipedia article already that covers the large majority of use-cases. Even if the standard were open, would anyone bother to read such a boring and lengthy document when a rare exception occurs? For the majority of users, a working knowledge is sufficient. Just like anyone recognises a hex nut and knows how to use it without ever reading ISO 4032. ArticCynda (talk) 20:48, 7 August 2022 (UTC)[reply]