Oct 24 2018
Oct 23 2018
@Mvolz I'm not sure what you mean by front end and back end. In any case, there are several methods that may be used to put information into the database, and several that may be used to extract information from the database. Some of these methods like RDF follow standards set by external organizations and we lack the ability to change them.
This specification is a non-starter because Wikidata supports both the Gregorian and Julian calendar while this spec only supports the Gregorian calendar.
Oct 17 2018
@Huji The task description talks about inputting data, not reading data that is already present.
Oct 16 2018
The task description gives a link and claims Arabic, Persian, Hebrew, Thai solar, Minguo and Japanese nengo are supported. But the link claims a time object must be acceptable to PHP's strtotime() function. The linked documentation for that function refers to https://php.net/manual/en/datetime.formats.php for the acceptable formats. That page has no mention of non-Gregorian calendar support.
The first day the Gregorian calendar was used was 15 October 1582. Dates before that should be converted to the other calendar supported by Wikidata, the Julian calendar.
Jul 17 2018
I would say the data model must be obeyed, and every aspect of the user interface must obey the data model. The presence of the word "century" in the user interface is a lie. This ticket should be closed as requesting the developers to refine a lie.
Jul 16 2018
One benefit would be to educate editors that the proper characters to indicate arcminutes or arcseconds is not the apostrophe or double quote respectively.
Jun 7 2018
Jun 6 2018
Jun 5 2018
May 30 2018
daniel's statement at 08:28 May 30 2018 is not correct. The spec daniel quotes states "...the time zone should be determined from the timezone field." The time zone field is always set to 0. Therefore the time zone is always UT. Daniel's statement "the spec is quite clear in saying that the time is indeed local time, always" is a direct contradiction of the spec.
Apr 29 2018
@Marsupium , perhaps the routines could be modified to recognize 11 as "day in local time, no time zone specified" and 11.5 as "day with time zone specified". But currently the data model emits precision as an integer, so all the consumers would have to be modified to accept 11.5 as a float. Not only that, if we start emitting 11 as a float, it will break all the existing emitters. If we emit 11 as an integer and 11.5 as a float, that will complicate consuming software because it will have to be flexible and accept either an integer or a float in that position.
Apr 26 2018
All existing dates have been entered without the ability to specify time zones. Sources for dates would typically include encyclopedias, biographic dictionaries (like ''American National Biography''), newspaper obituaries, etc. For such sources, the time zone is the time zone where the event took place, but this was '''falsely''' entered into Wikidata as UTC. The sources generally do not give the time of day of the event, so it is impossible to convert the date in local time to UTC.
Apr 9 2018
This is being discussed at Help talk:Dates on Wikidata.
Mar 29 2018
I'm skeptical about Wikidata considering that it can't get foot right. ( See https://www.wikidata.org/wiki/Q3710 )
Mar 28 2018
I disagree with Lucas_Werkmeister_WMDE. Help:Dates#Precision is correct. It agrees with[[ https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format | the RDF Dump Format ]] documentation and the the JSON documentation.
Dec 7 2017
Sep 3 2017
Jul 30 2017
Jul 24 2017
Since, historically, some countries have considered the year to begin, and incremented the year number on, a date other than January 1, we should specify that we always consider the year to begin on, and always increment the year number on, January 1, for bot the Gregorian and Julian calendars.
While being clear about the specification, we should specify that for both the Julian and Gregorian calendars, we consider the year to begin on, and the year number to be incremented on, January 1. Historically some countries have had other conventions.
Jul 5 2017
Making the timezone default to unspecified would require deciding how "unspecified" will be represented in all possible representations, including JSON, RDF, and the internal database value. If this approach is followed, I would like to see a bot go through the database and change all the existing timezone values to unspecified. Then correct values can be added once the facility to specified them becomes available, and as editors determine which values are correct.
Jun 28 2017
May 18 2017
May 17 2017
May 16 2017
If you're not going to follow a standard, you should go far away from the standard to avoid confusion. I'd suggest keeping the date and year field just as they are. In the absence of both those fields, the template could look for citoid-month, citoid-year, citoid-day, citoid-season, and whatever else is required.
Lots of tools and bots examine citations. I'm not really sure which ones examine the rendered HTML, which ones examine the COinS metadata, and which ones examine the wikitext. Anything that examines the wikitext and finds yyyy-mm-00 should reject it as completely non-standard.
May 14 2017
May 13 2017
The WMF should provide any of its employees working on this an official copy of ISO 8601 and they should be required to read it. Among other things, they would find that the only correct way to represent the current year is "2017". "2017-00" or "2017-00-00" are just wrong. Likewise, the only correct ways to represent the current year and month are "201705" or "2017-05"; "2017-05-00" is wrong.
May 12 2017
Jan 15 2017
Jan 10 2017
Oct 12 2016
I offer a list of test cases.
Oct 7 2016
I have been experimenting with various extreme values of the Julian year, as great as positive 10 billion, and am finding erratic results for the value of the julian date ($jd) and the Gregorian date ($gregorian). I found that for values that are too large, $jd could be 0, negative, or of the same order of magnitude as the year (when it should be about 365 times the year). Also, for values that are too large, $gregorian might or might not be "0/0/0".
Sep 25 2016
Sep 24 2016
Sep 23 2016
I have made a parallel request at the mediawiki talk page for Wikibase/Indexing/RDF_Dump_Format. There is no mention there of needing to submit a Phabricator ticket to change that documentation.
@Addshore asked for some examples of off-by-one years where the year is less than one.
Sep 22 2016
Now that the bot has begun to mark items, what is the procedure to follow when a marked item has been reviewed by an editor and found to be correct?
Sep 19 2016
Sep 14 2016
Sep 12 2016
Thanks to Addshore for the answer of Sep. 12, 17:54 UT.
It might be useful to state what range of dates will be checked, and what the source of the dates will be, since JSON and RDF dates state dates in different formats, and in the case of the flavor of RDF used in this link the form of the date depends on whether the software that produces the rdf was able to convert the date from Julian to Gregorian or not. Such irregularities might cause some dates that should be marked to be missed.
Aug 11 2016
I see the documentation of the JSON data model has been revised today; see this version from mediawiki. So now we have different formats, but our documentation now explains to users that these formats are intended to be different. That's a lot better. Now a few tweaks are still needed to make various parts reject or vilify dates they consider invalid, but this is a big step forward.
After the revision of the task description around 1700 UT on Aug 11, I see that the if the date was a Julian calendar date, WQS would convert the Gregorian date received from the RDF to the equivalent Julian date, and not mention in the display which calendar this is. I seriously question the decision of the UI authors to make fussy decisions about when to display the calendar and when not to. I think it would be better, and more resilient to any changes in this area in the UI, to always display the calendar.
I made a chart of what happens around AD 1. All these dates were entered in the sandbox today and all have had the calendar manually set to Gregorian during the entry process. (I accidentally entered 0000-01-22 while taking the default for this, Julian calendar, so I'm ignoring that date.) The diff column is the timestamp value one sees while viewing diffs between different versions of the sandbox.
Oh dear. Blazegraph recently went through an upheaval, switching from XSD 1.0 (where year 0000 does not exist and -0002 = 2 BCE) to XSD 1.1 (where year 0000 does exist and -0001 = 2 BCE). Also, there is controversy over whether the author(s) of the RDF formatter have correcty interpreted what is stored in the data base and are converting the year correctly.
I tend to favor displaying years before AD 1 with a combination of letters and numbers in the user interface, because different conventions have been used about what negative year numbers mean; no such ambiguity exists with "2 BC" or "2 BCE". I don't care whether AD/BC are used vs. CE/BCE.
There is considerable doubt about the correctness of the user interface. I suggest anyone undertaking this must obtain an ironclad definition of the meaning of the exact source WQS is obtaining the data from. Data entered into the database may have been entered with a variety of tools, not just the user interface. There is reason to suspect some of these tools would have treated -0001-01-01 as January 1, 2 BCE, while others would have treated it as January 1, 1 BCE. Thus, looking at examples of well-known BCE dates in the user interface is not a reliable way to judge the definition of the source of data that the user interface pulls from.
Aug 5 2016
Consider the item for Horace, Q6197. We know from Encyclopedia Britannica, among other sources, his actual date of death was 27 November 8 BCE of the Julian calendar. The user interface displays the same, 27 November 8 BCE. The documentation for the RDF and JSON seem to indicate they follow astronomical year numbering, and also ISO 8601 2004 edition, and acknowledge the existence of a year 0, so those formats should give the year as -7. If we use this url:
May 30 2016
I argue that entering the timezone when no time for the event is provided in the source is valid. For example the White House web site tells us Barack Obama was born August 4, 1961 in Hawaii. We know that Hawaii standard time is 10 hours behind UT, and Hawaii does not observe daylight time. We can safely conclude Obama was born between 04:00 August 3 and 14:00 August 4, UT. Providing the ability to input a correct time zone allows the information from most statements in sources about births and deaths to be faithfully reproduced.
The addition of the blocking task T136544: [Task] Validate timezones and block all timezones other than 0 changes, or clarifies, the interim defacto definition of day. In everyday life, a sentence like
Mar 17 2016
I have edited the description. It is not useful to record the positions of objects within the solar system (Moon, Saturn, etc.) in WikiData because they change too rapidly. The kind of objects which would have position information stored in WikiData would be stars, quasars, pulsars, galaxies, and the like. The kind of objects and the kind of data available for them can be explored at the US Naval Observatory's NOMAD catalog.
Mar 9 2016
I don't have experience coding in PHP, it appears PHP is a loosely typed language that converts among integers and floating point numbers implicitly, with no way to even declare which type a variable is. Trying to calendar programming in such a language is tricky, particularly since calendar programming is full of integer division and modulo operations that depend on the exact behavior of these functions, including how they work with negative numbers.
Mar 4 2016
It needs to be decided if this will actually be implemented with three separate fields for each angle (degrees, arcminutes, and arcseconds of declination and hours, time minutes, and time seconds of right ascension) or if a single decimal number will be used for each angle. I suggest it should not be a goal of this support to allow a round-trip conversion, but rather, to approximate the precision of the source in the manner usually followed by engineers and scientists. For example, if a source gave a R.A. as 3h 10m, but the implementors decided to store it as decimal hours, it should be stored as 3.17 h to reflect the precision of the source, not as 3.16666666666667 h or the like. If a data consumer were to convert 3.17 h back to h m s, he/she would get 3 h 10 m 12 s, and the responsibility would be on the data consumer to realize that the value was only given to three significant figures and so 3 h 10 m 12 s should be rounded to 3 h 10 m.
Feb 22 2016
Feb 20 2016
For the name RDF Dump Format I note that time already has a simple value and a full value. The simple value is already specified to be in the XSD 1.1 format if the full value can be converted to Gregorian. Would this simple value be sufficient?
Let's discuss which version of the schema to use a a starting point. You suggesthttps://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime . But the linked version of the schema does not allow year zero, the linked version of the schema purports to support leap second.
Feb 19 2016
An additional issue with borrowing the format from ISO 8601 (without using the definitions from ISO 8601) is that that standard requires a fixed number of digits for the years. So if the age of the universe is to be representable, today would have to be written 00000002016-02-26. Doing otherwise would force data consumers to check their ISO 8601 parsing software to see if it can handle our violations.
Feb 18 2016
The task description should be modified thus:
The description includes "the time zone (really?)" I infer the person who wrote that doesn't think time zones are very important. I, on the other hand, believe every date currently in Wikidata is false, except those close to 0° longitude, because they all say that the event occurred in a certain date time zone 0. I have not seriously begun correcting birth or death dates because Wikidata is currently incapable of storing the correct values.
Dec 21 2015
Dec 4 2015
Oct 30 2015
I would add that the question of whether, in the future, the transition from one day to the next should be determined by the rotation of the earth, or by atomic clocks which disregard the earth's rotation, will be the subject of (according to Rachel Courtland) a "fierce debate" at the World Radiocommunication Conference in November. Treating an international organization's standard as atomic-based when it is really rotation-based becomes more serious during a time when a "fierce debate" is raging.
xsd:dateTime reiterates the necessity of using the Gregorian calendar. The Gregorian calendar cannot possibly exist before the Earth, and Wikidata has a need to express dates that occurred before the Earth was formed. So either the TimeValue data type must be redefined to limit values to those that fall within the range of validity of the Gregorian calendar (the exact limits are not obvious) and a different data type created for dates in the far distant past or future, or we should stop naming or implying any external standard and acknowledge its something we made up ourselves, unrelated to ISO or the World Wide Web Consortium. It is not honest to knowingly ascribe to others statements that we know they did not make, such as the possibility of expressing the age of the universe in a notation that conforms to an ISO or W3C standard.
If our documentation or source code comments contain falsehoods then the Wikidata team is a pack of liars. ISO requires the Gregorian calendar. If you use an ISO-like notation to represent something other than the Gregorian calendar we are liars and Wikidata would deserve to be defunded. STOP WRITING ISO UNLESS YOU REALLY MEAN IT AND INTEND TO ABIDE BY EVERY SINGLE RULE IN THE SPEC.
Oct 29 2015
We have "universe" (Q1) which displays the start date as "
13798 million years BCE Gregorian" (Gregorian is a superscript). But the furthest back one could possibly extrapolate the proleptic Gregorian calendar was the first time the Earth rotated on its axis, which was much later (around 4,540 million years ago, measured in constant length seconds). So the date stated for the start of the universe in wikidata is false because the calendar was undefined and beyond any plausible extrapolation procedure at the time of the event.
The phrase "Gregorian ISO value" requires further consideration. For example, does it mean an ISO 8601 compliant value, or the strings currently in use which resemble ISO 8601 but permit a number of violations, such as "2015-00-00T00:00:00Z"?
Oct 10 2015
thiemowmde's quote from the buffalostate.edu site uses ellipsis to omit a critical passage: "Then, for your work in PHYS 152L, the uncertainty in the measurement is taken to be this value." This document is used in conjunction with an (apparently undergraduate) university course which adopts some shortcuts and simplifications for expediency in the course. The ability to read the display on an instrument is a lower bound on the uncertainty. Often an instrument will have other limitations that will cause the actual uncertainty to be greater than the uncertainty in reading the display. A simple example is that a meter stick bought at the local hardware store (UK: ironmonger) for $10 will probably disagree by more than one scale division from a quality engine-divided meter scale bought from a reliable manufacturer such as Starett for several hundred dollars.