[Wikidata-bugs] [Maniphest] T246731: WDQS date handling produces errors for Julian dates
Jc3s5h added a comment. I won't take issue issue with Delane13 changing the priority. I do think the general case for visualizing data in time is that the data about the events was originally recorded in a mixture of calendars, and usually there will be a desire to retrieve the calendar information so all the results of a query are in the same calendar so that they can be compared to each other. I think it is commonplace among researchers to have to convert dates themselves into their desired calendar and format. When large amounts of data are being handled, I think researchers will need automated tools for calendar conversions. TASK DETAIL https://phabricator.wikimedia.org/T246731 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Stinglehammer, Delane13, -jem-, AndrewNJ, Jc3s5h, Lydia_Pintscher, Epidosis, Jheald, agray, Gehel, Toni_001, Lucas_Werkmeister_WMDE, Mahir256, Tagishsimon, Aklapper, Danny_Benjafield_WMDE, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T247027: Add a « Gregorian mean year » ( Q87193822 ) unit to the Wikidata conversion table to normalize values that uses this unit
Jc3s5h added a comment. I see no reason to keep it open. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Lucas_Werkmeister_WMDE, Toni_001, Jc3s5h, Ladsgroup, Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T196674: Stop using "century" and "millennium" in association with Wikidata datetime data
Jc3s5h added a comment. The change in the Dates help page was made by Jarekt at 14:28, 17 July 2018 UTC. The edit summary states > Switched text from what "should" be the first and last year of decade century or millennium, to what is currently interpreted by the wikibase software I don't know about this edit, but other editors have been known to claim the wikibase software works a certain way, when what they really investigated was merely the user interface. TASK DETAIL https://phabricator.wikimedia.org/T196674 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Lea_Lacroix_WMDE, Jarekt, Jc86035, Jc3s5h, Ghouston, kaldari, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day on Wikidata
Jc3s5h added a comment.
In T57755#6593446 <https://phabricator.wikimedia.org/T57755#6593446>,
@Bouzinac wrote:
> Well, how one could write a timezone for {{Q|Q3062714}}, whose guillotine
worked on 10 h 22, Paris Time (given the fact that in 21 JAN 1793, UTC didn't
exist) ?
At present, we can't give the date and time when Louis XVI was executed. As
you can see from the discussion over the last 3 years, several substantially
different approaches have been suggested and no choice among them has been made
yet.
I don't know what time of day Louis XVI was executed, but I'll suppose for
the sake of discussion 10 h 22 m Paris time is correct. The first step is to
determine if this is apparent solar time or mean solar time. If it is apparent
solar time, and the time scale selected is a mean time scale, we would have to
convert it. I don't have a converter handy that would work for that date.
UTC didn't exist before about 1962. The time scale that has noon at Greenwich
occurring at 12 h 0 m, and can be projected back for many centuries, is UT1.
The longitude of Paris is 2.3522 degrees East. Each hour of mean time is
equivalent to 15 degrees of longitude, so 2.3522 degrees corresponds to 9
minutes. So mean Paris time is 9 minutes ahead of UT1.
TASK DETAIL
https://phabricator.wikimedia.org/T57755
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Bouzinac, Rehman, Nintendofan885, Multichill, Mahir256, BrokenSegue,
Wikirik123, PDrouin-WMF, SandraF_WMF, DannyS712, Abit, Magnus, Ramsey-WMF,
Addshore, valerio.bozzolan, Sabas88, Sannita, Paucabot, MisterSynergy,
Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo,
sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h,
Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand,
Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Akuckartz,
Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer,
_jensen, rosalieper, Scott_WUaS, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day on Wikidata
Jc3s5h added a comment. In T57755#6576646 <https://phabricator.wikimedia.org/T57755#6576646>, @Multichill wrote: > In T57755#6576583 <https://phabricator.wikimedia.org/T57755#6576583>, @Jc3s5h wrote: > >> >> >> There is no indication about what time zone will be assumed for the creation or first publication date. You can't expect users to provide correct dates and times if you don't tell them at the time of upload that whatever they enter will be assumed to have the time zone that was in force at the time and place where the photo was taken. > > That's how basic human interaction works? If I say that we'll meet next Saturday at 13:00, the other person knows it's in local time (just switched from CEST to CET). Works the same way on Commons. We don't ask users for time zones and we don't record that data. This is not basic in-person interaction. This is interaction among people all over the globe by means of computers. TASK DETAIL https://phabricator.wikimedia.org/T57755 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Multichill, Mahir256, BrokenSegue, Wikirik123, PDrouin-WMF, SandraF_WMF, DannyS712, Abit, Magnus, Ramsey-WMF, Addshore, valerio.bozzolan, Sabas88, Sannita, Paucabot, MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day on Wikidata
Jc3s5h added a comment. In T57755#6576706 <https://phabricator.wikimedia.org/T57755#6576706>, @Sannita wrote: > In T57755#6576583 <https://phabricator.wikimedia.org/T57755#6576583>, @Jc3s5h wrote: > >> I don't understand how a time could be without a timezone and at the same time have a default timezone. > > UTC can be used for this. Situation 1: time can be accompanied by a time zone, which could be UTC. In this case, the time zone is specified. Situation 2: the time zone of a time in a computer is not recorded. In this situation, the time must be judged from context. Situation 1 and situation 2 are mutually exclusive. TASK DETAIL https://phabricator.wikimedia.org/T57755 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Multichill, Mahir256, BrokenSegue, Wikirik123, PDrouin-WMF, SandraF_WMF, DannyS712, Abit, Magnus, Ramsey-WMF, Addshore, valerio.bozzolan, Sabas88, Sannita, Paucabot, MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day
Jc3s5h added a comment. > ! In T57755#6576484 <https://phabricator.wikimedia.org/T57755#6576484>, @Multichill wrote: > without timezones and default it to the local time? That is also current practice on Commons, see for example https://commons.wikimedia.org/wiki/File:Northstar_California_Prosser_2.jpg where the time is "3 July 2017, 13:28:12". If someone is really interested in the timezone, they can derive it from the coordinates. I don't understand how a time could be without a timezone and at the same time have a default timezone. I also don't understand how local time with hours, minutes, and seconds can be the current practice on Commons and at the same time require a software fix to allow entry of hours, minutes, and seconds on Commons. Finally, I see a lack of notice and documentation for file contributors. In the file upload dialog in Commons, the following instructions are provided to the uploader: > **Date work was created or first published** > Choose the date this work was created or first published. There is no indication about what time zone will be assumed for the creation or first publication date. You can't expect users to provide correct dates and times if you don't tell them at the time of upload that whatever they enter will be assumed to have the time zone that was in force at the time and place where the photo was taken. TASK DETAIL https://phabricator.wikimedia.org/T57755 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Multichill, Mahir256, BrokenSegue, Wikirik123, PDrouin-WMF, SandraF_WMF, DannyS712, Pintoch, Abit, Magnus, Ramsey-WMF, Addshore, valerio.bozzolan, Sabas88, Sannita, Paucabot, MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T247027: Add a « Gregorian mean year » ( Q87193822 ) unit to the Wikidata conversion table to normalize values that uses this unit
Jc3s5h added a comment. I stopped reading after the first paragraph of the "Description" because it is false. I quote it here, in case it is edited, so my comments will remain clear. > The annum unit is used in Wikidata statements to represent half life of isotopes, this is shown by this query. 1 annum = 1 gregorian mean year = 31 556 926 s The value is also cited by the NASA in this document as used currently for calendar calculation by them. Based on comments at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#%C2%AB_annum_%C2%BB_conversion_? I surmise that 31 556 926 s is based on this paper <http://doc.rero.ch/record/303694/files/pac-rec-09-01-22.pdf> by Holden et al. In that paper the length of the tropical year near AD 2000 is asserted to be 31 556 925.445 SI seconds. But the mean Gregorian year is not the same as the tropical year. As the NASA document (although intended for K-12 education) correctly states, the mean length of a Gregorian calendar day is 365.2425 **calendar days**. If we define a second to be 1/86400 calendar day, this is equal to 31,556,952 seconds. The length of these days has been measured in various ways, initially by simply observing the rising and setting of the Sun; later with astronomical observations of the Sun and stars to calibrate mechanical clocks in observatories. Today, atomic clocks are used but leap seconds are introduced at irregular, unpredictable intervals to keep calendar days in alignment with the observed rotation of the Earth on it's axis. So no precise SI equivalent can be given; it all depends on what period of time you decide to average over, and how much the rotation of the Earth on it's axis disagreed with atomic clocks during the averaging period. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Ladsgroup, Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification
Jc3s5h added a comment. In T207705#4691973, @Pigsonthewing wrote: In T207705#4690349, @Jc3s5h wrote: ISO 8601 being one of the rare exceptions As noted above: "ISO 8601-2019, due in the middle of that year, is expected to support all of the features of EDTF." Furthermore, as you can read at the linked page: "the EDTF specification is included as a profile of ISO 8601." My meaning was that nearly all notations, such as "July 1, 2018", "1 July 2018" "1 VII 2018" or "Solis Kandis Juliis MMXVIII" can refer to either the Gregorian or Julian calendar; this has been so for 400 years and that is what people are used to. ISO 8601 is one of the few notations that isn't supposed to be used with Julian dates; EDTF is another.TASK DETAILhttps://phabricator.wikimedia.org/T207705EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, Jc3s5hCc: Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification
Jc3s5h added a comment. In T207705#4690134, @Pigsonthewing wrote: Jc3s5h: This is now the third venue in which I have told you that there is absolutely no reason why we couldn't apply this only to Gregorian dates, as intended. And I will hunt down every place you have proposed this and make sure this serious disadvantage is mentioned. EDTF is human-readable. Humans have been using the same notation, in many formats and languages for Julian and Gregorian dates for 400 years, with ISO 8601 being one of the rare exceptions. And many ISO 8601 users are ignorant of the no-Julian restriction and therefore make mistakes. This human factors situation is an excellent reason to reject EDTF.TASK DETAILhttps://phabricator.wikimedia.org/T207705EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, Jc3s5hCc: Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification
Jc3s5h added a comment. @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.TASK DETAILhttps://phabricator.wikimedia.org/T207705EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, Jc3s5hCc: Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification
Jc3s5h added a comment. This specification is a non-starter because Wikidata supports both the Gregorian and Julian calendar while this spec only supports the Gregorian calendar.TASK DETAILhttps://phabricator.wikimedia.org/T207705EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, Jc3s5hCc: Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T189746: Have a calendar converter for input dates at wikidata
Jc3s5h added a comment.
@Huji The task description talks about inputting data, not reading data that is already present.
When it comes to Wikidata, ISO is a dirty word. First of all, Wikidata supports two calendars, Gregorian and Julian. ISO 8601 only allows Gregorian. So whenever you write ISO, you are writing that you are going to ignore all Julian dates that have been entered into WIkidata, or you are going to falsify them by pretending they are Gregorian when they are not.
Using Isaac Newton as an example, his birthdate is December 25, 1642, Julian. Looking at the page source, one find this (just cut and paste, no attempt to get the whole statement, whatever that is)
{\"mainsnak\":{\"snaktype\":\"value\",\"property\":\"P569\",\"datavalue\":{\"value\":{\"time\":\"+1642-12-25T00:00:00Z\",\"timezone\":0,\"before\":0,\"after\":0,\"precision\":11,\"calendarmodel\":\"http://www.wikidata.org/entity/Q1985786\"}
If one interprets the "1642-12-25" but ignores "http://www.wikidata.org/entity/Q1985786\" one gets the wrong answer.TASK DETAILhttps://phabricator.wikimedia.org/T189746EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Huji, Jc3s5h, Mehdi, Doostdar, alanajjar, Aklapper, Yamaha5, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, dachary, LawExplorer, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T189746: Have a calendar converter for input dates at wikidata
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T189746EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, 4nn1l2, Mehdi, Doostdar, alanajjar, Aklapper, Yamaha5, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, dachary, LawExplorer, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T189746: Have a calendar converter for input dates at wikidata
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T189746EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, 4nn1l2, Mehdi, Doostdar, alanajjar, Aklapper, Yamaha5, dachary, Wikidata-bugs, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. In T95553#4430944, @Jarekt wrote: Phabricator tickets are not a good place to debate the definitions of phrases like "20th century". The meaning of that term was defined a long time ago and should not depend on Wikidata or other software. I am no expert on the matter but articles on individual centuries on Wikipedias (I checked English and German ones) list "20th century" as timeperiod between January 1, 1901 and ended on December 31, 2000, and that did not change in last 15 years. It might be counter intuitive and not compatible with some software, but it seems like that is the understanding of the term. We should not debate the meaning of "century" except to decide if it is compatible with the data model, which must be obeyed. Since many (not everyone, but many respectable sources) interpret the 21st century to begin 1 January 2001 and end 31 December 2100, the word "century" is not compatible with the data model and should not be used anywhere in the user interface.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc86035, Jarekt, Sylvain_WMFr, Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc86035, Jarekt, Sylvain_WMFr, Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T196674: Stop using "century" and "millennium" in association with Wikidata datetime data
Jc3s5h added a comment. In T196674#4430825, @Jarekt wrote: Current Wikibase definition of beginning and ending years of a century and millennium are in synch with the definitions in the English or German Wikipedia, see :de:19._Jahrhundert for example. Maybe Wikibase software could just provide a link to the item like Q6955 to clarify the definition, and where we can specify the date range. Wikibase is not a single thing. It is made up of many parts, and currently the user interface disagrees with all the other parts about what range is indicated when the precision is set to 7.TASK DETAILhttps://phabricator.wikimedia.org/T196674EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jarekt, Jc86035, Jc3s5h, Ghouston, kaldari, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...Because of Wikibase's nonstandard date handling, some dates labelled "20. century" may actually be interpreted as a time in the period 2000–2099 by Wikibase components other than the user interface, and by software other than Wikibase.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc86035, Jarekt, Sylvain_WMFr, Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. In T95553#4430864, @Jc86035 wrote: (My earlier description edits were incorrect and were based on a bad interpretation of the project chat discussion with complaints about external tools. The thing that causes the issue is that some software doesn't realize that Wikibase has nonstandard date handling and has slightly different ranges for centuries and millennia.) I would say rather that most of Wikibase follows much of ISO 8601:2004, and in particular, follows that standard with respect to centuries, for example, when 4 digit years are being used, the precision is century, and the first two digits of the year are 20, then the date could be anywhere from 1 January 2000 to and including 31 December 2099. So most of Wikibase follows a widely used standard. But the user interface is inconsistent with the rest of the Wikibase code and documentation. External code does not interact through the user interface. Whether the external code correctly follows the Wikibase standards, as documented in the data models, would depend on whether the external code was developed by reading the data models, or empirically by looking at data present in the database. If the data that the external developers happened to have incorrect information due to the faulty user interface, the external code might be faulty as well.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc86035, Jarekt, Sylvain_WMFr, Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. In T95553#4265262, @kaldari wrote: @Jc3s5h: I created a new bug for you here: T196674. Now I respectfully ask that you stop spamming this bug with unrelated discussion. Thank you. No.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. I In T95553#4262897, @kaldari wrote: @Jc3s5h: This bug has nothing to do with accurately expressing ranges. This bug is about the fact that "5. century" is not valid English and is confusing to English speakers and should be changed to "5th century" (or if that's too hard, "5 century"). If the word "century" is abandoned, then this bug is moot, but that doesn't mean that this is the right place to talk about accurately representing 100-year ranges. I disagree with the notion that one can't discuss, within this bug, whether any solution with the word "century" in it is wrong.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. In T95553#4259798, @kaldari wrote: It looks like y'all are actually discussing T73459, so please feel free to continue there. I think the solution for both T73459 and this bug would have to involve avoiding the word "century" on both input and output, so the discussion applies to both bugs.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment.
In T95553#4259766, @kaldari wrote:
Can y'all please open separate bugs for these other issues and not just dump them all in this bug? Thanks.
A solution must output an _expression_ that will accurately indicate the possible 100 year periods that can be represented in the data model. Using the notation that an "(" excludes the endpoint of an interval and "[" includes the endpoint of an interval:
.
.
.
[1 Jan 101 BC, 31 Dec 2 BC]
[1 Jan 1 BC, 31 Dec AD 99]
[1 Jan AD 100, 1 Jan AD 199]
.
.
.
I have not seen a solution proposed that unambiguously expresses these ranges.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. In T95553#4256969, @Lucas_Werkmeister_WMDE wrote: The insignificant digits are not always set to zero – you can manually set any date you like and then adjust the precision (example edit). And when you do that, the input shows you how your edit will be interpreted: F18803384: Screenshot-2018-6-5 Wikidata Sandbox.png It shows how it will be displayed by the user interface, which is different from how it should be interpreted by the specs, and potentially different from how it will be interpreted by all the other software that's been created inside and outside of Wikimedia Foundation projects.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Ghouston, Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Block] T87764: Bugs related to time datatype (tracking)
Jc3s5h reopened subtask T67267: Specify whether TimeValue stores timestamps in UTC or local time. as "Open". TASK DETAILhttps://phabricator.wikimedia.org/T87764EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Mike_Peel, PokestarFan, T.seppelt, Agabi10, Ricordisamoa, Conny, Liuxinyu970226, JulesWinnfield-hu, Wikidata-bugs, Tobi_WMDE_SW, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T67267: Specify whether TimeValue stores timestamps in UTC or local time.
Jc3s5h reopened this task as "Open".Jc3s5h added a comment. 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. The only way I can imagine a person might write "the spec is quite clear in saying that the time is indeed local time, always" is if the person was thinking of the local time of the Wikidata servers, and the Wikidata servers are set to UTC. But such an interpretation of "local time" is invalid. "Local time" means the local time of the place where the event associated with a Wikidata date occurred. For example, the local time associated with the birth of George Washington is that of Westmoreland County, Virginia, 78.6 degrees west longitude. That would be -307 minutes in the data model, if and when non-zero values are supported.TASK DETAILhttps://phabricator.wikimedia.org/T67267EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, Jc3s5hCc: PokestarFan, Jc3s5h, Wikidata-bugs, Lydia_Pintscher, daniel, JohnLewis, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T57755: allow time values more precise than day
Jc3s5h added a comment. @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.TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T57755: allow time values more precise than day
Jc3s5h added a comment. 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. I see two possible approaches. Rewrite the data model to limit precision to day or looser, and define all dates to be in unspecified local time. Rewrite all the output routines to omit timezone and not put a Z at the end of ISO-8601-like strings. Create a new data type that fully supports time zones. Create a new data type that supports local time (time zone unspeified). Rewrite all date-holding fields to accept either the existing data type, or the new local time data type. When implementing the change, lock the database and run a bot to change all existing data types to the new local time data type. All old data will be deemed to have an unspecified time zone; only data added after the change will have the possibility of having a time zone. A disadvantage of this approach is that existing external tools that accomodated themselves to the bad behavior of WIkidata will continue to add local times and falsely proclaim them to be UTC. TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. This is being discussed at Help talk:Dates on Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English
Jc3s5h added a comment. 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. As for the idea that "1800s" means the decade from 1800 to 1809, the Chicago Manual of Style 16th ed. page 476 states Note that the first decade of any century cannot be treated in the same way as any other decades. "The 1900s," for example, could easily be taken to refer to the whole of the twentieth century. TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin, Lucas_Werkmeister_WMDE, Sjoerddebruin, Marsupium, PKM, Liuxinyu970226, TheDJ, Lydia_Pintscher, kaldari, Ricordisamoa, daniel, thiemowmde, Lucie, Amire80, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Conny, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, LawExplorer, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T145532: HH:MM:SS time in Wikidata (new datatype or display option for quantity datatype?)
Jc3s5h added a comment. In T145532#3818480, @Mike_Peel wrote: Don't forget to include the time zone! The proposal is not for expressing time-of-day, it is to express a duration. Durations do not have time zones. What if the duration is more than 24 hours? Should the quantity allow durations greater that 24 hours to be expressed as w days, x hours, y minutes, z seconds?TASK DETAILhttps://phabricator.wikimedia.org/T145532EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Mike_Peel, daniel, thiemowmde, Liuxinyu970226, ArthurPSmith, Izno, Aklapper, Esc3300, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, Zoranzoki21, Wikidata-bugs, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T112075: [Story] When editing quantities, allow units to be entered directly into the text input field.
Jc3s5h added a comment. In T112075#3484280, @Lydia_Pintscher wrote: I think we need to keep consistency in mind here. We have at least one other place where we use the same mechanism right now: selecting a language for monolingual text values. We should also think about selecting globes, precision and time zone in the future. Which of those should behave the same and which differently? Gut feeling: I like two fields better because it makes it a bit clearer that you are selecting an existing item for the unit and can't just type anything. @Lydia_Pintscher asked which should behave the same and which differently. Precision: we should decide if precision, which will ultimately be translated into a decimal upper and lower bound, should attempt to mimic the precision stated in the source, or should be a round decimal number that approximates the precision stated in the source. For example, if a source states latitude and longitude is accurate to +/- 1 arcsecond, should that be represented by making the lower bound less than, and the upper bound greater than. the nominal value by 0.00027° or by 0.0003°? Time zone: since most sources do not provide time zones, and it can be challenging to determine what time zone offset was in effect at the time of an event, there should be an ability to state the time zone is local time. The current documentation of the data model describes the time zone as an integer. This won't do in the future. Globe: fairly straightforward for objects on the surface of the earth, but different notation and applicability for celestial objects (right ascension and declination for stars and galaxies, not applicable for position of planets and comets as seen from Earth). TASK DETAILhttps://phabricator.wikimedia.org/T112075EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Agabi10, Sjoerddebruin, PokestarFan, Charlie_WMDE, Jan_Dittrich, James_Budday, Esc3300, daniel, Aklapper, Jonas, Lydia_Pintscher, Jc3s5h, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)
Jc3s5h added a comment.Herald added a subscriber: PokestarFan. 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.TASK DETAILhttps://phabricator.wikimedia.org/T146499EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: PokestarFan, Esc3300, Lydia_Pintscher, daniel, thiemowmde, Yair_rand, Liuxinyu970226, Pasleim, Aklapper, Jc3s5h, GoranSMilovanovic, Ivana_Isadora, QZanden, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67267: Specify whether TimeValue stores timestamps in UTC or local time.
Jc3s5h added a comment.Herald added a subscriber: PokestarFan. 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.TASK DETAILhttps://phabricator.wikimedia.org/T67267EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: PokestarFan, Jc3s5h, Wikidata-bugs, Lydia_Pintscher, daniel, JohnLewis, GoranSMilovanovic, QZanden, Izno, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)
Jc3s5h added a comment. In T146499#3406504, @Esc3300 wrote: As a first step, we might just consider that "unused" means "unspecified". I think it's safe to say the developers would be unwilling to emit contradictory information in the RDF dump format (and related RDF formats) and the JSON format. As I understand it, neither of these formats defines how date/times should be represented, and the representation standards for Wikidata were created by Wikidata developers. Neither standard indicates that the timezone may be omitted. and neither standard indicates the Z at the end of the datetime string may be omitted. Changing these representations would be a breaking change; various parsers written both inside and outside the Wikimedia organization may be unable to read the new format. For the more distant future, for RDF, since it tries to follow ISO 8601, there will be an issue of how to represent a date with a timezone but no time of day. For example, if I wanted to represent "today" in my time zone in ISO 8601, the nearest I can come to it is "2017-05-2017T-04:00" but I don't think there is consensus about whether this is a valid ISO 8601 representation.TASK DETAILhttps://phabricator.wikimedia.org/T146499EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Esc3300, Lydia_Pintscher, daniel, thiemowmde, Yair_rand, Liuxinyu970226, Pasleim, Aklapper, Jc3s5h, GoranSMilovanovic, Ivana_Isadora, QZanden, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T146499EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Esc3300, Lydia_Pintscher, daniel, thiemowmde, Yair_rand, Liuxinyu970226, Pasleim, Aklapper, Jc3s5h, GoranSMilovanovic, Ivana_Isadora, QZanden, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T73867: wikidata's JS Time input: adding "after" and "before" for range of time
Herald added a project: Wikidata. TASK DETAILhttps://phabricator.wikimedia.org/T73867EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Wikidata-bugs, Yamaha5, Lydia_Pintscher, Unknown Object (MLST), GoranSMilovanovic, QZanden, Izno, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T145898: Wikidata time DataType should emit HTML
Jc3s5h added a comment. In T145898#2645449, @Esc3300 wrote: Sounds like another calendar model trap (W3C spec requires Gregorian) I agree. Also, Wikibase emits lots of stuff. This task does not sufficiently specify the context in which some thing like "13 November 2007" is emitted.TASK DETAILhttps://phabricator.wikimedia.org/T145898EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Esc3300, Izno, Aklapper, D3r1ck01, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T155062: Allow entry of globe field, and provide display of globe field, for coordinate location in Wikidata
Jc3s5h created this task.Jc3s5h added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently when viewing a coordinate location with the Wikidata user interface, the globe field is not displayed. See https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON#globecoordinate for a description of the globe field, and https://www.wikidata.org/wiki/Q689195 for an example of an item where the globe is not the default, Earth. The ability to enter the globe field should be provided so those who use the user interface can add coordinate locations on solar system objects other than Earth, and the field should displayed so editors can verify the correctness of the field, especially in the case of solar system objects other than Earth. Such provision will also eliminate the motivation to create properties to work around this limitation, such as this property proposal.TASK DETAILhttps://phabricator.wikimedia.org/T155062EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Aklapper, Jc3s5h, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T98194: [Bug] Date parser does not allow February 29, 1700 (Julian)
Jc3s5h added a comment. I offer a list of test cases.TASK DETAILhttps://phabricator.wikimedia.org/T98194EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: T.seppelt, Tobi_WMDE_SW, Jonas, gerritbot, Jc3s5h, daniel, thiemowmde, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T146356: [Bug] RDF export misses extreme values with day precision
Jc3s5h reopened this task as "Open".Jc3s5h added a comment. 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". I should add that I don't have another tool at my disposal to independently convert Julian to Gregorian for enormous dates, so I can't say for sure if the correction in PHP is correct between the years 101,994 and 1,465,071, only that there are no obvious problems. I found the largest Julian calendar date that does not produce any obvious problem is y = 1465072, m = 9, d = 17. This results in $jd = 536,838,867. The value of $gregorian is "10/17/1,465,102" (thousand separators added). A simple solution, if you don't mind not converting less than a year's worth of dates in the distant future, is to add a test that the Julian year must be < 1465072.TASK DETAILhttps://phabricator.wikimedia.org/T146356EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, Jc3s5hCc: gerritbot, hoo, aude, Lydia_Pintscher, Jc3s5h, Smalyshev, Jonas, thiemowmde, Aklapper, mschwarzer, Avner, Lewizho99, Maathavan, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. In T105100#2629763, @Addshore wrote: The source of the dates are the values stored in the backend JSON, so what is in the database, and what you can see throguh the API. Yes, but the lists that are now provided in the task description use Wikidata Query Service, which in turn relies on RDF Dump Format. I have not experimented to discover if this will hide any instances. It will cause the dates displayed in the list (if the date contained in the database is Julian) to be converted from Julian to Gregorian, if the RDF related software is capable of doing the conversion.TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Ymblanter, Edgars2007, Multichill, joeroe, Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. In T105100#2665020, @Addshore wrote: Yes, so once added the statements are safe to remove, they will not be re added by a future run as I have a list of GUIDs to be skipped in the future! (the lists are essentially the same as the lists published earlier in this ticket). The GUIDS will remain the same throughout changes to the statement, the one exception is when items are merged, where statements are moved from one item id to another. I'm not familiar with how the GUIDs are generated. Will statements be protected from future runs if, for example, the correction is carried out by deleting the incorrect birth date and creating a new birth date property. Or if there are two birth dates, one of which is marked and incorrect, the other is unmarked but incorrect. So the marked incorrect one is deleted and the unmarked incorrect one is fixed, say, by making what was an AD 1600 Gregorian birth date a Julian date.TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Ymblanter, Edgars2007, Multichill, joeroe, Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T146356: [Bug] RDF export misses extreme values with day precision
Jc3s5h added a comment. In T146356#2663757, @Smalyshev wrote: I think this idea makes a lot of sense. While I think all far-ago dates that have day precision are most probably data errors (you can't have May 4th in 20BC, really, at least not using Earthly calendars :) handling these errors in more sane manner is good. However, I think we need then to change precision, if we operate under year precision, we can't just take year and then claim day precision. It'd be claiming false data. A person using the RDF may just want the best idea of the date that the RDF processing can give. But the person might also be performing quality control on the underlying data that flowed into the internal representation to RDF conversion process. It would be nice to somehow indicate that the date had to be approximated due to limitations of the RDF conversion process. (Perhaps leave it for the data consumer to figure out for him/her/itself that May 4th in 20BC is silly?)TASK DETAILhttps://phabricator.wikimedia.org/T146356EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, Jc3s5hCc: gerritbot, hoo, aude, Lydia_Pintscher, Jc3s5h, Smalyshev, Jonas, thiemowmde, Aklapper, mschwarzer, Avner, Lewizho99, Maathavan, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. In T105100#2659241, @Addshore wrote: @Jc3s5h This should be as simple as removing the instance of qualifier. We of course have the lists of all statements that will be touched in this run of the script. If we do ever do a future run we will still have that list of guids that we can avoid! In the posts at https://www.wikidata.org/wiki/User_talk:Succu#Questionable_revert user Succu seems to feel that verifying entries, and memorializing the fact that they have been verified by removing the appropriate properties, is allowable until some sort of public announcement is made.TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Ymblanter, Edgars2007, Multichill, joeroe, Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. I verified the dates for In T105100#2659241, @Addshore wrote: @Jc3s5h This should be as simple as removing the instance of qualifier. We of course have the lists of all statements that will be touched in this run of the script. If we do ever do a future run we will still have that list of guids that we can avoid! I notice you said lists of all statements touched. What if a statement is found to be incorrect and is corrected. For example, it is a Gregorian date and, after consulting the supporting source, it is changed to Julian. Can we be assured a future run will not then mark it as a suspicious Julian calendar date with day precision?TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Ymblanter, Edgars2007, Multichill, joeroe, Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. In T105100#2662859, @Addshore wrote: In T105100#2659966, @Multichill wrote: @Addshore looking at https://upload.wikimedia.org/wikipedia/commons/c/ca/Wikidata_Calendar_Model_Decision_Tree.svg your bot is not following it. The bot followed this tree up to the first level, at which point human intervention is needed. @Multichill the two edits edits that you have linked appear to be for statements that have no references. Per the decision tree we should try and find references for these to ensure they are correct. And I think it is most unlikely that the dates are correct. I have never encountered books, encyclopedias, etc. that state dates as Gregorian dates even though the Julian calendar was in force at the time and place of the events, as is the case for the two edits complained about.TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Ymblanter, Edgars2007, Multichill, joeroe, Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment.
{{u|addshore}} asked for some examples of off-by-one years where the year is less than one.
One example is Pacorus I of Parthia who died in 38 BC. The accepted value in Wikidata is 38 BC, but a pending edit shows 37 BC, even though the reference in the pending edit shows 38 BC. This indicates either the editor requesting the pending edit was confused, or the tool the editor was using was faulty.TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Edgars2007, Multichill, joeroe, Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. 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?TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Esc3300, Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T92996: Figure out how to represent non-Gregorian dates in RDF export
Herald added a project: Discovery. TASK DETAILhttps://phabricator.wikimedia.org/T92996EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, Jc3s5hCc: Jc3s5h, gerritbot, Manybubbles, daniel, Aklapper, Smalyshev, mschwarzer, Avner, Lewizho99, Maathavan, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. Thanks to Addshore for the answer of Sep. 12, 17:54 UT. I'm not fully up on all the jargon. Is this link: https://www.wikidata.org/wiki/Special:EntityData/Q4115189.json an example of what Addshore referred to in the statement "The source of the dates are the values stored in the backend JSON, so what is in the database, and what you can see throguh the API."TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105100: [Task] Run bot to mark dates that need checking for calendar model correctness
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T105100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, Jc3s5hCc: Candalua, Ricordisamoa, Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata
Jc3s5h added a comment. 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. But of course the converter can't be written until the notation used in the source the converter is receiving input from is known with certainty. You use the term "raw value" and explain I can see it if I hover over the date. Can you explain where this raw date comes from? Is it identical to the value stored in the data base, or is some conversion done to it from the time it leaves the data base to the time I see it on the screen? If you can assure me no conversion is done, that would be enough to make me start using WQS on a regular basis. Thanks for your replyTASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Smalyshev, daniel, thiemowmde, Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata
Jc3s5h added a comment. In T142198#2544939, @Smalyshev wrote: Since most dates will be Gregorian, I doubt always displaying calendar is beneficial. Either make sure every date displayed is Gregorian, or make sure the calendar is displayed. Otherwise the person who used to working with Gregorian but one day has to work with Julian will be confused as hell. Imagine if a poor German bought a car that accidentally an odometer that worked in miles.TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Smalyshev, daniel, thiemowmde, Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata
Jc3s5h added a comment. In T142198#2544647, @Smalyshev wrote: We can not know with certainty what whoever have put the dates into Wikibase meant. What however we can do is to define how we interpret the user input and stored data. And we have no choice but to do that - we have to put *something* in the output, and by the fact of putting that into output we are defining our interpretation. True. What we can do is decide what the dates should mean and then correct all the methods of putting data in to reject invalid dates. It would be nice if all public-facing interfaces always required dates like -01-01 or the equivalent 1 January 1 BC (with suitable synonyms for the words & numbers format). Also adjust all displays to either refuse to display invalid dates, or display them together with an indication they are invalid. In a test I did, I noticed that RDF, for a date I stored in the second sandbox by entering -01-30, Gregorian calendar, because it didn't conform you you're interpretation of what the internally stored dates meant. Bravo! Keep it up.TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Smalyshev, daniel, thiemowmde, Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata
Jc3s5h added a comment. In T142198#2544647, @Smalyshev wrote: 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. Could you please explain what you mean? I'm the author of the RDF format (at least one of :) and I am not aware of any "controversy" - RDF follows XSD 1.1, and it's the industry standard. If you have observed some bugs there please submit a ticket. But of course the converter can't be written until the notation used in the source the converter is receiving input from is known with certainty. We can not know with certainty what whoever have put the dates into Wikibase meant. What however we can do is to define how we interpret the user input and stored data. And we have no choice but to do that - we have to put *something* in the output, and by the fact of putting that into output we are defining our interpretation. Right now the dates in the DB and JSON follow (roughly) the XSD 1.0 standard for serializing dates, but the RDF follows XSD 1.1 since it is accepted standard in semantic data world. The last date - -01-30 - doesn't seem to be valid, i.e. it does not describe any actual point on the date scale. Wikibase may sometimes allow to enter nonsensical values (including February 30th, etc.), but RDF can not really represent it. JSON, RDF, the user interface, and the time stamp of the date shown in diffs are presenting seemingly conflicting information to the public. Therefore, they're all wrong. Just like part of a marching band is playing Yankee Doodle, another part is playing Lucy in the Sky with Diamonds, and a third part is playing Deutschlandlied. That band isn't getting invited back next year. First decide what to follow and implement in one of these. Then get a commitment from the other parts to quickly implement corrections and document it all over WikiData, the data models in Wikimedia, etc.TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Smalyshev, daniel, thiemowmde, Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata
Jc3s5h added a comment. 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. On a related note, if you attempt to adjust the display according to the precision, you could get into trouble if your not careful. If the date was entered as 4 January 500 BCE Julian calendar, century precision, it would be displayed as 6. century BCE. When RDF converts that to 30 December 501 BCE its now in the 6th century BCE, so if you try to match the display of dates with precision worse than day, you must do the back-conversion to Julian before you try to decide how to display it. Finally, better make sure your Gregorian to Julian conversion routines works for the same range of dates as the RDF Julian to Gregorian converter does. Neither has a prayer of working for the start date of item Q1 (what does a year even mean when the earth doesn't exist yet)?TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Smalyshev, daniel, thiemowmde, Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata
Jc3s5h added a comment. 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 -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. entereddiffUI displayRDFJSON 1 January 2 BCE-0002-01-011 January 2 BCE-0001-01-01-0002-01-01 8 January 1 BCE-0001-01-088 January 1 BCE-01-08-0001-01-08 15 January 1+0001-01-1515 January 10001-01-15+0001-01-15 -01-30+-01-3030 January 0ignored+-01-30 TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: daniel, thiemowmde, Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata
Jc3s5h added a comment. Oh dear. Blazegraph recently went through an upheaval, switching from XSD 1.0 (where year does not exist and -0002 = 2 BCE) to XSD 1.1 (where year 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 suspect there may be an inactivity timeout in this system, so I will submit this now and add more later.TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jonas, Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata
Jc3s5h added a comment. 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.TASK DETAILhttps://phabricator.wikimedia.org/T142198EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Aklapper, Esc3300, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T129823: BC (Before Christ) times are not correct in wikidata
Jc3s5h added a comment. 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: https://www.wikidata.org/wiki/Special:EntityData/Q6197.json to access the JSON (which I understand is regarded by developers as cannonical) the result is "-0008-11-27T00:00:00Z". If the JSON really is cannonical, then the user interface is storing the input incorrectly and displaying the stored value incorrectly. If we look at the RDF using this URL: https://www.wikidata.org/wiki/Special:EntityData/Q6197.rdf the result is "-0007-11-25T00:00:00Z" The RDF software has correctly converted 27 November of the Julian calendar to 25 November of the Gregorian calendar, just as its documentation says it will, but it has an inexcusable contradiction about the year, compared to the JSON. The situation is so bad that no documentation, no code, and no dates in the data base for years < 1 can be believed. We need a definitive decision that is strongly pushed in the face of everyone who deals with dates.TASK DETAILhttps://phabricator.wikimedia.org/T129823EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Esc3300, Jc3s5h, Luo123n, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T76859: Allows to input of plain text such as "today" in time edit widget
Herald added a subscriber: TerraCodes. TASK DETAIL https://phabricator.wikimedia.org/T76859 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: TerraCodes, Jc3s5h, jhsoby, Sjoerddebruin, Ricordisamoa, Liuxinyu970226, Addshore, Lydia_Pintscher, daniel, JanZerebecki, thiemowmde, revi, adrianheine, Snaterlicious, Aklapper, Multichill, Tpt, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T136544: [Task] Validate timezones and block all timezones other than 0
Jc3s5h added a comment. 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 <https://www.whitehouse.gov/administration/president-obama> 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. TASK DETAIL https://phabricator.wikimedia.org/T136544 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Izno, hoo, Jonas, aude, daniel, Lydia_Pintscher, JanZerebecki, adrianheine, Aklapper, thiemowmde, Zppix, D3r1ck01, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T102930: [Bug] Entering times used to be blocked with "not supported" but is not any more
Jc3s5h added a comment. The addition of the blocking task T**136544: [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 > Obama was born on August 4, 1961, at Kapiʻolani Maternity & Gynecological Hospital (now Kapiʻolani Medical Center for Women and Children) in Honolulu, Hawaii; he is the first President to have been born in Hawaii. is understood to be a statement with precision "day". The Hawaii time zone is understood to be part of the day. By saying the time zone must be set to zero, together with the nearly universal practice of copying whatever the source says into Wikidata, the defacto minimum precision on Wikidata is two days, not one day. TASK DETAIL https://phabricator.wikimedia.org/T102930 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: adrianheine, Ricordisamoa, JanZerebecki, Jc3s5h, Lydia_Pintscher, daniel, aude, thiemowmde, Aklapper, WMDE-Fisch, D3r1ck01, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T127950: Support celestial coordinates
Jc3s5h added a comment. 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 <http://www.usno.navy.mil/USNO/astrometry/optical-IR-prod/nomad>. Modern star catalogs use the International Celestial Reference System. Except for the most accurate data, this is equivalent to a system centered on either the barycenter of the solar system or the center of the Sun, using the equator and equinox of J2000.0 (a date close to the beginning of the year 2000. TASK DETAIL https://phabricator.wikimedia.org/T127950 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Swpb, Nikki, Aklapper, Micru, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T127950: Support celestial coordinates
Jc3s5h edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T127950 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Swpb, Nikki, Aklapper, Micru, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T127950: Support celestial coordinates
Jc3s5h edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T127950 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Swpb, Nikki, Aklapper, Micru, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T106923: [Task] add phpt testcases to prove reports regarding bugs in PHP calendar conversion function for julian date and day
Jc3s5h added a comment. 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. My intuition is that many of the bug reports will be people feeding floats into functions only intended to use ints, or people who tried to predict the results with a desk calculator and didn't get the integer divisions right. If JanZerebecki has identifed some bug reports that JanZerebecki thinks are valid, it might be useful to list them. I have a widely respected book by Dershowitz & Reingold, //Calendrical Calculations//, which has tables giving examples of significant dates in several calendars, over a wide range of years. I would be happy to list some of these dates, and even test them in PHP. Is there any particular format that the test cases should be in? (Sure, I've never used PHP, but I've been adding languages to my collection since the days of punched cards.) TASK DETAIL https://phabricator.wikimedia.org/T106923 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, thiemowmde, Krenair, Aklapper, JanZerebecki, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T127950: Support celestial coordinates
Jc3s5h added a comment. 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.17 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. If we are storing decimal numbers, we should use significant figures and rounding in the manner customary among scientists and engineers. If our goal were to perfectly represent the source, we would keep it as an arbitrary string, but then we wouldn't be able to do computation with it. TASK DETAIL https://phabricator.wikimedia.org/T127950 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Swpb, Nikki, Aklapper, Micru, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T127950: Support celestial coordinates
Jc3s5h edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T127950 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Swpb, Nikki, Aklapper, Micru, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T117031#2050075, @Smalyshev wrote: > We are currently using XSD 1.1 format in both cases, and in both cases the date is (proleptic) Gregorian. I think Smalyshev didn't use the word "currently" clearly in this sentence. Maybe he means "the proposal as currently envisioned". But he can't mean the current version of WikiData, because the current version has no Julian to Gregorian conversion software, and quite a few dates in the database are currently stored in the Julian calendar. A different question: what programming language would the future Julian to Gregorian routine be written in. Maybe I can find something, or translate something. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. For the [[mw:Wikibase/Indexing/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? TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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 seconds, and the linked version of the schema has a different representation for time zones than a more recent version. A later version, https://www.w3.org/TR/xmlschema11-2/#d-t-values defines as 1 BC, does not support leap seconds (but nevertheless purports to use UTC), and represents time zones as an offset measured in minutes. I don't think we can proceed unless we decide which version of the schema to use as a starting point. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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 0002016-02-26. Doing otherwise would force data consumers to check their ISO 8601 parsing software to see if it can handle our violations. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T89005: [Story] JSON should (optionally) contain expanded/normalized values.
Jc3s5h added a comment. The task description should be modified thus: Replace "UTC (gergorian)" with "Universal Time <https://en.wikipedia.org/wiki/Universal_Time> and Gregorian calendar". UTC did not exist before about 1961 (the earliest listed conversion from UTC to UT1 on page 87 of //Explanatory Supplement To the Astronomical Almanac// 3rd ed., editors Urban & Seidelmann, is for January 1, 1961). An open question is what to do about precisions. If a date is given as January 1, 1980, Central European Time, with a precision of one day, the usual interpretation would be the event occurred between 00:00 hrs and 24:00 hrs in that time zone. If the normalization only considers the beginning of the possible range, converts it to 23:00 December 31, 1979, and omits the time zone and precision, the result is a bit misleading. TASK DETAIL https://phabricator.wikimedia.org/T89005 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Jonas, Ricordisamoa, Addshore, JanZerebecki, thiemowmde, Tobi_WMDE_SW, Lydia_Pintscher, Aklapper, daniel, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T59930: Representation of time inside TimeValue objects should depend on the calendar model
Jc3s5h added a comment. Herald added a subscriber: Aklapper. 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. TASK DETAIL https://phabricator.wikimedia.org/T59930 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Aklapper, vlsergey, Jc3s5h, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, daniel, Izno, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T57755: allow time values more precise than day
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T57755 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Izno, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T59704: Support Julian Date (astronomy)
Jc3s5h edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T59704 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Ricordisamoa, Filceolaire, Aklapper, Jc3s5h, Wikidata-bugs, thiemowmde, Micru, adrianheine, Snaterlicious, Lydia_Pintscher, daniel, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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 <http://spectrum.ieee.org/tech-talk/computing/networks/leap-second-heads-into-fierce-debate>) 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. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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.** TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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**-**00**T00:00:00Z"? Also ISO 8601 requires the Gregorian calendar, which is a solar calendar based on counting actual sunrises and sunsets. For events in the distant past, most astronomy and other science is based on constant-length seconds such as produced by an atomic clock (see the Wikipedia article "Delta T". The difference between these two approaches grows to a full day about the year 3400 BC. Thus ISO 8601 is not fit for use in prehistoric times. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF
Jc3s5h added a comment. 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. TASK DETAIL https://phabricator.wikimedia.org/T117031 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, aude, daniel, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. 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. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jonas, JanZerebecki, harej-NIOSH, Thryduulf, Mike_Peel, Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1660386, @daniel wrote in part: > . . . > - the //magnitude// of the uncertainty interval should be order of magnitude > of the least significant digit (not twice that -- so +/-0.5, not +/-1). That's OK for a guessed uncertainty, but is not a requirement for a specified uncertainty. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: harej-NIOSH, Thryduulf, Mike_Peel, Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1657039, @daniel wrote, in part: > > We can of course discuss if, when and how the explicit +/-X is shown to the > user. I'm completely open to that. One sensible suggestion was to hide it if > the actual uncertainty is the same as what we would assume from the decimal > representation. In that case, it's OK to hide it, I think. Maybe also if the > precision is better than what we would assume. Maybe. But in any case it's > crucial to understand that we *have* do consider uncertainty everywhere if we > want to allow conversion. I would always show the uncertainty if it comes from a source. This would let editors know that checking the uncertainty of a number is a lower priority than unsourced guesses about uncertainty. It also lets a reader know the referenced source could be checked to verify the uncertainty, in case what the reader was really interested in was the uncertainty of the number. > We could store "unknown", and then re-calculate the uncertainty every time we > need it, but why? What would that gain us? We could store the guess about uncertainty, but also mark it as unknown, so data consumers would be on notice they really ought to find a better source if they care about the uncertainty. > Well, in scientific literature at least, a number like 2.30 or 2.3e3 has a > definite uncertainty (resp significant digits). It's given by convention of > the notation. Would you consider that a guess, or a sourced uncertainty? In a scientific source I would certainly consider 2.30 or 2.3e3 as a sourced uncertainty if it was from a scientific source. For a number like 2300, I would also regard it as a sourced uncertainty. But I would also infer that the uncertainty of the number was not especially important in the article, or that the article, although from a scientific organization, was intended for a popular audience, or both. An example is a recent press release from the US Geological Survey, giving the elevation of Mt. Denali to the nearest foot. We can tell it is intended for a popular audience because the uncertainty was not explicitly stated, and because the elevation was given only in feet. One would expect that when the peer-reviewed journal article comes out, the primary unit of length will be the meter, with perhaps an occasional conversion to feet. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Mike_Peel, Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1660251, @Mike_Peel wrote, in part: > > ...The standard approach in astronomy (which is the part of the scientific > literature that I'm most familiar with, as a scientist working in that field) > is to quote a number along with the uncertainty and the significance level > associated with that uncertainty. I think that's the standard approach in most fields of science and engineering, in the most serious works, for numbers that are the main focus of the article, chapter, book, etc. But these kind of sources are not always readily available to Wikidata contributors. Wikidata contributors may use other databases, or articles intended for a popular audience, which are reliable but lack explicit statements about uncertainty. The Wikidata numbers might also come from sources that mention a number in passing and so do not explicitly state an uncertainty. Unfortunately trying to impose a rule that only the //best// sources may be used to introduce data into Wikidata just isn't going to happen. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Mike_Peel, Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1657997, @daniel wrote in part: > @Jc3s5h what, then, would be an example for a reliable/acceptable source > giving us a number with no hint at the uncertainty? When should we consider > an uncertainty unsourced? If Nature gives the size of a crater on Mars in > kilometers, what uncertainty should we assume, and should it be considered > sourced? We must also allow for the case where there is no reliable source. Normally a reliable source would give us an uncertainty, implicitly or explicitly; the main exception that comes to mind would be a quantity that is just mentioned in passing; something that is not the main focus of the document. "Explicitly" would include a description of the method used to determine the quantity, including the accuracy of the method, even if the description was in a different part of the document. "Implicitly" usually be the number of significant figures for the item in Wikidata, together with the number of significant figures for other items in the source measured in the same way. If a source described a method for measuring the elevation of mountain summits, then said the elevation of Mt. X was 2013 m, Mt. Y was 2000 m, and Mt. Z was 7253 m, we have a sourced statement that the uncertainty of Mt Y is 2000 m ± a few meters. > I'm afraid the distinction of sourced vs unsourced uncertainty makes things > harder to handle in code and more difficult to understand for users. > > I suggest we do what we always do, really: we assume that people follow the > establish conventions when entering data. Most people never think of > significant digits or uncertainties explicitly, but we all used the concept > intuitively, all the time, when we say that the store is "two hundreds yards > away" or it's "170 Miles to Sometown". I agree. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Mike_Peel, Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T99674: Decide on internal representation of (Gregorian and Julian) dates with negative years
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T99674#1648463, @daniel wrote, in part: > > When referring to "ISO", please note that ISO 8601 actually *changed* from > representing 44BC as -44 to now using -43 to represent that year. And then, > later, XSD followed that change. That's the root of the confusion. So if you > say "ISO", please be clear whether you mean the old or the new interpretation. I would request that contributors not use "ISO" at all, because ISO requires the Gregorian calendar and only the Gregorian calendar. Wikidata now supports both Julian and Gregorian calendar. TASK DETAIL https://phabricator.wikimedia.org/T99674 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Ricordisamoa, JanZerebecki, Smalyshev, Jc3s5h, daniel, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Addshore, Liuxinyu970226, Rical, Conny, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment.
I must take issue with thiemowmde's argument:
- "At this point, this is false precision. The original value was not that
precise. The original 1.06 feet had 2 decimal places, the last being 0.01 feet
= 0.003048 m."
Suppose we do as thiemowmde suggests; when the user enters 1.06 feet in the
user interface, with no ± character and no uncertainty specified, we store {
amount: 1.06, unit: feet, upperBound: 1.06, lowerBound: 1.06 } We no longer
have the user's original input; we now have a declaration that the value is
exactly 1.06 feet. If the user had entered 1.06±0 because the user knew the
value was exact, it would be stored exactly the same way. So if it is converted
to meters the value becomes 0.323088±0 m.
TASK DETAIL
https://phabricator.wikimedia.org/T105623
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher,
Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r,
Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper,
aude
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T94064: Date of +0000-01-01 is allowed but undefined in wikibase but is not allowed in xsd:dateTime as implemented by blazegraph
Jc3s5h added a comment. I created https://phabricator.wikimedia.org/T112703: "Fix display of dates in user interface". This bug touches on how a date will be stored in wikibase and dealt with by XSD, but not how it will be displayed in the user interface. The current display in the user interface is wrong. TASK DETAIL https://phabricator.wikimedia.org/T94064 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Ricordisamoa, thiemowmde, Jc3s5h, Lydia_Pintscher, Denny, Manybubbles, daniel, mkroetzsch, Smalyshev, JanZerebecki, Aklapper, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T107870: Illegal dates in date type
Jc3s5h added a comment. Please see https://phabricator.wikimedia.org/T89246. As a non-developer who has not been coding any of this stuff, I was astonished to learn that after = 0 and after = 1 mean the same thing. So the following two TimeValues mean the same thing (assuming unmentioned parameters have the same value): time = +2013-01-01T00:00:00Z precision = 11 before = 0 after = **0** timezone = 0 calendarmodel = https://www.wikidata.org/wiki/Q12138 time = +2013-01-01T00:00:00Z precision = 11 before = 0 after = **1** timezone = 0 calendarmodel = https://www.wikidata.org/wiki/Q12138 That is, they both declare that an event occurred at a point in time that isn't exactly known, but falls between 00:00 hours 1 January 2013 and 00:00 hours 0 January 2013 Coordinated Universal Time. If the before value were set to 1 in either case, I imagine the event would have occurred between 00:00 hours 31 December 2012 and 00:00 hours 0 January 2013 Coordinated Universal Time; have I got that right? I think the concept of after = 0 and after = 1 meaning the same thing is so astonishing that it needs to be advertised far and wide at every opportunity. TASK DETAIL https://phabricator.wikimedia.org/T107870 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, daniel, Magnus, Ricordisamoa, thiemowmde, hoo, Lokal_Profil, Aklapper, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T107870: Illegal dates in date type
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T107870 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, daniel, Magnus, Ricordisamoa, thiemowmde, hoo, Lokal_Profil, Aklapper, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. > We cannot assume that trailing zeros are insignificant. The default > uncertainty for 7000 should be the same as the default uncertainty of > (currently +/-1, possibly to be +/-0.5 in the future). "seven thousand" can > be written as 7e3 to indicate that only the 7 is significant. This would > currently be interpreted as 7000+/-1000 (possibly to become +/-500 in the > future). Yes, we can interpret trailing zeros to the left of the decimal point as not significant, unless the tolerance is specified explicitly with the ± symbol That is standard practice in science and engineering. For example, //Land Surveyor Reference Manual// 2nd ed. by Andrew Harbin p. 108 states: "A zero is //not// significant if it occurs at the end of a measured number unless information is available which indicates that it is." Some people may be ignorant of this convention, but by default we should adopt the greatest reasonable uncertainty. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1623500, @Jc3s5h wrote: > If the least significant digit is m time ten to the nth power, I would set > the default uncertainty to 5 times ten to the nth power, which is the > greatest uncertainty that might apply in that situation. If the uncertainty > were any worse, the person who wrote the value should have used fewer > significant digits. In other words, the default should be the worst > reasonable uncertainty; let the editor specify if the error is better than > this. On further reflection, I would do what I described above, unless there was only one significant digit. In that case I would set the precision to 1 times ten to the n. Examples: 7000 ± 1000; 1920 ± 50. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T112247: [RFC] Create a "number" datatype for exact values
Jc3s5h added a comment. Exact numbers can occur not only through counting, but also through definition. For example, as explained by the US National Geodetic Survey <http://www.ngs.noaa.gov/PUBS_LIB/FedRegister/FRdoc59-5442.pdf>, one yard is defined as exactly 0.914 4 meter. One could imagine properties in Wikidata where most of the instances are measured, and have an associated uncertainty, but a few instances are defined, and so are exact. So unless it can be proven that a certain property is //always// uncertain, or //always// exact, the property should be designed to accept either the proposed number type, or QuantityValue. If it isn't possible or practical to make properties take either kind of number, I don't see any choice but to use QuantityValue with amount = lowerBound = upperBound. TASK DETAIL https://phabricator.wikimedia.org/T112247 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: daniel, Lydia_Pintscher, Liuxinyu970226, Snaterlicious, jayvdb, SPQRobin, Wikidata-bugs, DSGalaktos, Bugreporter, geraki, Ayack, Gareth, kaldari, Smalyshev, Izno, AmaryllisGardener, Sjoerddebruin, Mbch331, Stryn, Denny, Jc3s5h, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
Jc3s5h added a comment. If the least significant digit is m time ten to the nth power, I would set the default uncertainty to 5 times ten to the nth power, which is the greatest uncertainty that might apply in that situation. If the uncertainty were any worse, the person who wrote the value should have used fewer significant digits. In other words, the default should be the worst reasonable uncertainty; let the editor specify if the error is better than this. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
