[Wikidata-bugs] [Maniphest] [Commented On] T87312: User interface displays false birth and death dates

2015-01-23 Thread Jc3s5h
Jc3s5h added a comment. In reply to Lydia_Pintscher: I enter Galileo in search box. A dropdown appears and I click Galileo Galilei. The item page for Galileo Galilei (Q307) appears. I scroll down to date of birth. The box reads: date of birth 25 February 1564 Julian There is also a link

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-26 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T66084 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences

[Wikidata-bugs] [Maniphest] [Commented On] T88437: figure out current state of time storage and display

2015-02-04 Thread Jc3s5h
Jc3s5h added a comment. Documentation says dates are represented in conformance with ISO 8601, with a fixed 11 digits for the year. ISO 8601 requires that all dates be expressed in the Gregorian calendar. We have no format defined to store a Julian calendar date. Considering that the authors

[Wikidata-bugs] [Maniphest] [Commented On] T88437: figure out current state of time storage and display

2015-02-04 Thread Jc3s5h
Jc3s5h added a comment. I wish to point out this edit: https://www.wikidata.org/w/index.php?title=Q692diff=193453963oldid=193042089 It creates a timestamp +0001564-00-00T00:00:00Z But of course month 0 and day 0 are not valid ISO 8601 values. The proper ISO 8601 representation of a date

[Wikidata-bugs] [Maniphest] [Commented On] T88437: figure out current state of time storage and display

2015-02-04 Thread Jc3s5h
Jc3s5h added a comment. In response to Candalua's comment, consider that the Julian calendar was used in Europe. Outside Europe, some countries converted directly from a calendar that was neither Gregorian nor Julian to Gregorian. The Julian-to-Gregorian switch occurred at many different times

[Wikidata-bugs] [Maniphest] [Commented On] T88437: figure out current state of time storage and display

2015-02-04 Thread Jc3s5h
Jc3s5h added a comment. I would add to Addshore's comment that ordinarily dates of death and birth should be considered local time; usually there will not be sufficient information to convert to a date that begins and ends at midnight universal time. TASK DETAIL https

[Wikidata-bugs] [Maniphest] [Created] T87312: User interface displays false birth and death dates

2015-01-21 Thread Jc3s5h
Jc3s5h created this task. Jc3s5h added a subscriber: Jc3s5h. Jc3s5h added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION If the user interface is invoked by typing, for example, Galileo Galilei in the search box and clicking on the obvious item

[Wikidata-bugs] [Maniphest] [Commented On] T88438: spec of how timevalue works and is supposed to work

2015-02-10 Thread Jc3s5h
Jc3s5h added a comment. I note thiemowmde's patch for review at Feb 6, 16:32 says what we are doing now is: //* URI identifying the calendar model. The actual time value should be in this calendar model, - but note that there is nothing this class can do to enforce this convention

[Wikidata-bugs] [Maniphest] [Commented On] T88438: spec of how timevalue works and is supposed to work

2015-02-19 Thread Jc3s5h
Jc3s5h added a comment. The code comment state above does not constitute a decision. I don't know if this project allows important decisions to be made without discussion and hidden in code comments. Even if that is allowed, there is still no decision. There is only a general concept

[Wikidata-bugs] [Maniphest] [Commented On] T88438: spec of how timevalue works and is supposed to work

2015-02-19 Thread Jc3s5h
Jc3s5h added a comment. Releasing fixes ASAP before deciding how dates should be stored seems like putting the cart before the horse, unless you plan to release an additional patch later after we decide how to store dates. TASK DETAIL https://phabricator.wikimedia.org/T88438 REPLY HANDLER

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-26 Thread Jc3s5h
Jc3s5h added a comment. I am unable to find any tool that promises to return the data in exactly the form it is stored in the Wikidata database. I did find one method of displaying the contents of an item; an example of the url is https://www.wikidata.org/wiki/Special:EntityData/Q692.json

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-27 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T66084#996435, @thiemowmde wrote: Uh, what? What about fixing the documentation? It's marked as //This document is a draft, and should not be assumed to represent the ultimate structure// anyway. My original question

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-27 Thread Jc3s5h
Jc3s5h added a comment. ISO 8601 says The interchange parties shall agree the additional number of digits in the time element year. I believe thiemowmde is incorrect in claiming that this can mean the data exchange partners can agree to a variable number of digits. Other parts of the standard

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-26 Thread Jc3s5h
Jc3s5h added a comment. In light of Addshore's comment of January 26, 2015, 23:12, I would say that a bot must be created to change every date so the year contains exactly 16 digits, and every date with a different number of digits is invalid. TASK DETAIL https://phabricator.wikimedia.org

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-26 Thread Jc3s5h
Jc3s5h added a comment. ISO 8601:2000 contains the following requirement: If, by agreement, expanded representations are used, the formats shall be as specified below. The interchange parties shall agree the additional number of digits in the time element year. In the examples below it has

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-01-27 Thread Jc3s5h
Jc3s5h added a comment. In reply to thiemowmde, P570 (Date of death; the same argument applies to P569, Date of birth) |has datatype TimeValue. The description of the datatype is at https://www.mediawiki.org/wiki/Wikibase/DataModel. The first element the TimeValue structure is described

[Wikidata-bugs] [Maniphest] [Commented On] T66084: Time data-type inconsistently zero-pads year value (dates earlier than year 1000?)

2015-02-10 Thread Jc3s5h
Jc3s5h added a comment. Please see my proposed ISO 8601 profile for Wikidata https://www.wikidata.org/wiki/User:Jc3s5h/ISO_8601_profile_for_Wikidata. I believe the points in that user page need to be addressed, even if we decide on a different result than I propose. TASK DETAIL https

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-03-17 Thread Jc3s5h
Jc3s5h added a comment. I tested JavaScript: document.write(new Date( 1900, 1, 29 ).toDateString()) Which gave as a result Thu Mar 01 1900 So this indicates that the JavaScript Date object is the wrong tool for the job we are doing. I haven't tested PHP, but that is suspect too. So the code

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-03-17 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T85296 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-03-17 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T85296#973355, @Addshore wrote: Okay, so when entering 31 September 1949 through the Frontend in an edit and saved it is formatted as 1 October 1949 and correctly saved as +019-10-01T00:00:00Z This suggests that the date

[Wikidata-bugs] [Maniphest] [Commented On] T72395: Displaying (and editing) the calendar model of time values is confusing

2015-03-04 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T72395#1088223, @Conny wrote: Do not know right position. User mentioned that it makes no sense to declare dates as gregorian before calendar reform. ISO 8601 uses the (possibly proleptic) Gregorian calendar for all dates. When

[Wikidata-bugs] [Maniphest] [Commented On] T88438: spec of how timevalue works and is supposed to work

2015-02-23 Thread Jc3s5h
Jc3s5h added a comment. thiemowmde's comment of Monday, Feb. 23, 11:07 seems to only consider parsers and validators known to the development team. Maybe it's a fact that no one has ever written a good ISO 8601 parser or validator that can process years with more than 4 digits; I have never

[Wikidata-bugs] [Maniphest] [Commented On] T88438: spec of how timevalue works and is supposed to work

2015-02-23 Thread Jc3s5h
Jc3s5h added a comment. In response to thiemowmde's post of Mon., Feb. 23, 17:21, I suggest that rather than marking //calendartime// obsolete, we mark it reserved for support of calendars other than proleptic Gregorian and proleptic Julian, with no usage rules decided upon yet. TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T75272: Time-Parser should detect most likely calendar

2015-04-20 Thread Jc3s5h
Jc3s5h added a comment. Looking at the title of this task, Time-Parser should detect most likely calendar, I think it should be explicitly stated what time parser(s) this task will consider; the time parser(s) used to take date input from users who employ the user interface, the time parser(s

[Wikidata-bugs] [Maniphest] [Commented On] T93256: Documentation of year 0 and negative years

2015-05-15 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. Jc3s5h added a comment. This is described as documentation. But isn't there some part of Wikidata that parses input and stores it in some unstated format? Isn't there some other part of Wikidata that parses the stored format and output it in what seems

[Wikidata-bugs] [Maniphest] [Commented On] T85324: DataValue Time recognizes the ISO date value not very well in Korean language.

2015-05-15 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. Jc3s5h added a comment. In https://phabricator.wikimedia.org/T85324#996337, @Addshore wrote: 2011-4-19 is clearly the 19th of April 2011, so why not parse this too? Yes, 2014-4-19 is pretty clearly the 19th of April 2011. But the string 2011-4-19 does

[Wikidata-bugs] [Maniphest] [Commented On] T93256: Documentation of year 0 and negative years

2015-05-18 Thread Jc3s5h
Jc3s5h added a comment. ISO 8601:2004_E states **--calendar year** is, unless specified otherwise, represented by four digits. Calendar years are numbered in ascending order according to the Gregorian calendar by values in the range [] to []. Values in the range [] through [1582

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T94539: BlazeGraph uses old xsd:dateTime standard

2015-05-19 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T94539 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, JanZerebecki, Manybubbles, Thompsonbry.systap, Haasepeter, Beebs.systap, Aklapper, Smalyshev

[Wikidata-bugs] [Maniphest] [Commented On] T94539: BlazeGraph uses old xsd:dateTime standard

2015-05-19 Thread Jc3s5h
Jc3s5h added a comment. As far as I can tell Wikidata's statement to data contributors and users about the meaning of dates stored in Wikidata is at [[mw:Wikibase/DataModel/JSON]]. The [ earliest version] dated 29 April 2014 states time: Date and time in ISO notation. The 2004 version of ISO

[Wikidata-bugs] [Maniphest] [Commented On] T94539: BlazeGraph uses old xsd:dateTime standard

2015-05-20 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T94539#1298550, @daniel wrote: @Smalyshev is it correct to say that at the moment, Julian dates are converted to XSD 1.1 dates, but Gregorian dates stay XSD 1.0 in our output? I think we should have an option for switching the XSD

[Wikidata-bugs] [Maniphest] [Commented On] T94539: BlazeGraph uses old xsd:dateTime standard

2015-05-20 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T94539#1298906, @daniel wrote: @Jc3s5h XSD is always Gregorian, but the question is which year numbering should be used in the output. This is regardless of whether the date is Gregorian or Julian internally. It's purely

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T59704: Support Julian Date (astronomy)

2015-05-19 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T59704 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Wikidata-bugs, thiemowmde, Micru, adrianheine, Snaterlicious, Lydia_Pintscher, daniel, aude

[Wikidata-bugs] [Maniphest] [Commented On] T94064: Date of +0000-01-01 is allowed but undefined in wikibase but is not allowed in xsd:dateTime as implemented by blazegraph

2015-05-19 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T94064#1296543, @daniel wrote: @mkroetzsch precise dates for prehistoric times may be useful for astronomical events. These could/should use a different calendar model though, such as https://en.wikipedia.org/wiki/Julian_day

[Wikidata-bugs] [Maniphest] [Commented On] T94539: BlazeGraph uses old xsd:dateTime standard

2015-05-20 Thread Jc3s5h
Jc3s5h added a comment. Am I correct to think that this ticket is **only** about how to represent 1 BCE in RDF. Thus, the fact that RDF is strictly (possibly proleptic) Gregorian while Wikidata also supports Gregorian is outside the scope of this ticket, so conversion between Gregorian

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T99795: RdfBuilder should have an option to switch between XSD 1.1 and XSD 1.0 style dates in the output.

2015-05-20 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T99795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Smalyshev, Aklapper, daniel, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, JanZerebecki

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T89246: Correct and update documentation for time in DataModel description on mediawiki.org

2015-06-07 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T89246 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Snaterlicious, thiemowmde, Tobi_WMDE_SW, Wikidata-bugs, Addshore, Aklapper, aude

[Wikidata-bugs] [Maniphest] [Commented On] T73459: Wrong parsing of centuries and millennia

2015-06-21 Thread Jc3s5h
Jc3s5h added a comment. This was discussed at https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Years/Archive_11#When_do_centuries_and_millennia_begin.3F It seems that most modern official and academic sources in English-speaking countries prefer the view that the 3rd millennium began

[Wikidata-bugs] [Maniphest] [Commented On] T102930: Wikidata time type properties allow adding a time in the UI but backend checks reject it

2015-06-21 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. Jc3s5h added a comment. If one enters the input as 1 January 1 01:01 in the user interface the message Precision higher than DAY is not yet supported and the save button is greyed out. Perhaps a more serious fault of the user interface is it does not provide

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T73459: Wrong parsing of centuries and millennia

2015-06-21 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T73459 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Wikidata-bugs, GPHemsley, Krenair, thiemowmde, Snaterlicious, Lydia_Pintscher, daniel, aude

[Wikidata-bugs] [Maniphest] [Commented On] T99795: RdfBuilder should have an option to switch between XSD 1.1 and XSD 1.0 style dates in the output.

2015-06-25 Thread Jc3s5h
Jc3s5h added a comment. In reply to the comment of Smalyshev on Wed, Jun 24, 23:47 UT. As far as I know, there is no proposal to use automation to fix the bad entries in the database. So what they get changed to depends on the good judgement of the editor who has looked up the source

[Wikidata-bugs] [Maniphest] [Commented On] T102930: Wikidata time type properties allow adding a time in the UI but backend checks reject it

2015-06-22 Thread Jc3s5h
Jc3s5h added a comment. The user interface now allows the entry of a birth date of `1 January 1900 00:00-300`, that is, midnight on the east coast of the US in winter. It also allows the entry of `+1900-01-01T00:00-05:00`. By examining this diff https://www.wikidata.org/w/index.php?title

[Wikidata-bugs] [Maniphest] [Commented On] T102930: Wikidata time type properties allow adding a time in the UI but backend checks reject it

2015-06-22 Thread Jc3s5h
Jc3s5h added a comment. The title if this issue is Wikidata time type properties allow adding a time in the UI but backend checks reject it. A properly implemented UI would clearly define in a manner accessible to the user what is allowed, allow saving of everything that is allowed

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T95532: allow localized input of time values

2015-06-10 Thread Jc3s5h
Jc3s5h removed a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T95532 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Liuxinyu970226, gerritbot, Ayack, hoo, thiemowmde, Aklapper, Lydia_Pintscher, Wikidata-bugs, aude

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T87574: Wrong time parsing of ISO dates with day 00

2015-06-16 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T87574 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Tobi_WMDE_SW, Jc3s5h Cc: Jc3s5h, Accurimbono, Tobi_WMDE_SW, JanZerebecki, gerritbot, daniel, adrianheine

[Wikidata-bugs] [Maniphest] [Commented On] T67253: Make TimeValue represent an interval always.

2015-06-16 Thread Jc3s5h
Jc3s5h added a comment. I think there are two distinct meanings. First, there is an event that has a duration much less than the precision. For example, Benjamin Franklin died on April 17, 1790 in Philadelphia; our article does not give the time of death. Supposing that the editor who placed

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T67267: Specify whether TimeValue stores timestamps in UTC or local time.

2015-06-16 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T67267 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Wikidata-bugs, Lydia_Pintscher, daniel, JohnLewis, aude, Malyacko, P.Copp

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T87074: Please provide human readable timestamps in api response

2015-06-16 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T87074 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Addshore, JanZerebecki, aude, daniel, Liuxinyu970226, kaldari, bmansurov, Aklapper, Jdlrobson

[Wikidata-bugs] [Maniphest] [Updated] T72395: Displaying (and editing) the calendar model of time values is confusing

2015-06-01 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T72395#1325530, @daniel wrote: What's the status of this? We have changed the interpretation of the internal model as well as the UI and API quite a bit with regard to the calendar model. Ignoring the fact that the data we

[Wikidata-bugs] [Maniphest] [Commented On] T99795: RdfBuilder should have an option to switch between XSD 1.1 and XSD 1.0 style dates in the output.

2015-07-02 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T99795#1419479, @Smalyshev wrote: Year zero doesn't make sense for Wikidata because 1BCE is stored as -1, so what 0 would be? I don't see any actual year to be represented by it. If storage format changes then we'll need to change

[Wikidata-bugs] [Maniphest] [Commented On] T89218: For special precision in Wikidata interface, show dimension in meters

2015-07-06 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. Jc3s5h added a comment. The dimension of an object is different than the precision. The horizontal dimensions of the [[en:Middlebury to Her Soldiers (sculpture)]] monument appears to be about 3 m. But if I were the one who had to measure the location, my

[Wikidata-bugs] [Maniphest] [Commented On] T99795: RdfBuilder should have an option to switch between XSD 1.1 and XSD 1.0 style dates in the output.

2015-07-01 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T99795#1419257, @Smalyshev wrote: So I think we should adopt the following approach for getting from Wikidata datetime to ISO/XSD datetime: 1. If date is Gregorian and positive - check it for ISO format breakage (0 day/month, 31

[Wikidata-bugs] [Maniphest] [Commented On] T99674: Decide on internal representation of (Gregorian and Julian) dates with negative years

2015-05-24 Thread Jc3s5h
Jc3s5h added a comment. In reply to Rical' comment of Sun, May 24, 08:41 the current documentation is at https://www.mediawiki.org/wiki/Wikibase/DataModel and https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON I understand that the before and after fields were intended, when a date

[Wikidata-bugs] [Maniphest] [Commented On] T99674: Decide on internal representation of (Gregorian and Julian) dates with negative years

2015-05-25 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T99674#1311475, @Rical wrote: To convert geographic position to a time more accurate than a day we must conform to the rules of each country. Rare are the countries which use solar time as local time. Now mainly Pacific Ocean

[Wikidata-bugs] [Maniphest] [Commented On] T99674: Decide on internal representation of (Gregorian and Julian) dates with negative years

2015-05-21 Thread Jc3s5h
Jc3s5h added a comment. To get things moving, I'll make a proposal. 1. The following fields from the internal representation (as shown in JSON) are essential to correctly interpret a time datatype: time, timezone, precision, and calendarmodel 2. The first change to the meaning of the existing

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77978: Support unit conversion

2015-08-19 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T77978 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Aklapper, daniel, Wikidata-bugs, aude, Malyacko

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-08-11 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T85296#1526755, @daniel wrote in part: That is exactly what Wikidata's TimeValues are. No more and no less. True. But the user interface only supports Julian or Gregorian; I don't know if the API would prevent the addition

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T101754: [Bug] When editing quantities, do not put the unit label in the input field

2015-08-14 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T101754 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Lydia_Pintscher, Jonas, Aklapper, daniel, Wikidata-bugs, aude, Malyacko

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-08-10 Thread Jc3s5h
Jc3s5h added a comment. In reply to daniel's comment at Aug. 1-, 16:14, it seems to me it would be more common to find, in a source, a date given in an ancient calendar that can't be precisely converted to Gregorian, than it would be to find a date that purports to be Julian or Gregorian

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-08-10 Thread Jc3s5h
Jc3s5h added a comment. I would agree with @thiemowmde if there were a plausible alternative to the Gregorian and Julian calendars which might require support in the future. But I believe that any such alternative would be so drastically different that there would be no temptation to apply

[Wikidata-bugs] [Maniphest] [Commented On] T77982: Decide on implementation of Unit Selector widget

2015-08-10 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T77982#1524501, @daniel wrote in part: 2. For the common subscripts and superscripts, there are unicode characters that can be used, see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts. For units we'll

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-08-10 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T85296#1524522, @daniel wrote in part: @Jc3s5h: You mean, we could have a calendar model for Broken Gregorian? I like that idea! My concern with a Broken Gregorian calendar model is the well-demonstrated willingness of editors

[Wikidata-bugs] [Maniphest] [Commented On] T77982: Decide on implementation of Unit Selector widget

2015-08-10 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T77982#1524674, @Ricordisamoa wrote: In https://phabricator.wikimedia.org/T77982#1524580, @Jc3s5h wrote: I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable

[Wikidata-bugs] [Maniphest] [Commented On] T85296: Wikibase API allows adding impossible dates such as 31 September 2014

2015-08-12 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T85296#1531136, @thiemowmde wrote in part: we do know which Gregorian and Julian dates exist. I think we do not (https://en.wikipedia.org/wiki/February_30), but even if we do, how does this change anything? Why should

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T105100: run bot to mark dates that need checking for calendar model correctness

2015-07-22 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T105100 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, Jc3s5h Cc: Jc3s5h, daniel, Tobi_WMDE_SW, Addshore, Aklapper, Lydia_Pintscher, Wikidata-bugs, aude

[Wikidata-bugs] [Maniphest] [Commented On] T105100: run bot to mark dates that need checking for calendar model correctness

2015-07-22 Thread Jc3s5h
Jc3s5h added a comment. Old dates might have been determined from historical records, or might have been determined by astronomical calculations (date of an eclipse, for example). Morrison and Stephenson provide an equation showing the difference between counting actual days by sunrises

[Wikidata-bugs] [Maniphest] [Commented On] T105100: run bot to mark dates that need checking for calendar model correctness

2015-07-24 Thread Jc3s5h
Jc3s5h added a comment. {{ping|Lydia_Pintscher}} I am not an expert on ancient calendars. Duncan Steel in //Marking Time: The Epic Quest to Invent The Perfect Calendar// (Wiley, 2000, page 36) mentions Sumerian records around 3500 BC. I don't know if any of these can be connected to a modern

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77977: Unit support (tracking)

2015-07-20 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T77977 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Mike_Peel, Luke081515, Wolfvoll, -jem-, Lucie, Izno, JanZerebecki, Smalyshev, Filceolaire

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77982: Decide on implementation of Unit Selector widget

2015-07-20 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T77982 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher, Jc3s5h Cc: Jc3s5h, Yair_rand, Micru, Ricordisamoa, Bene, Lydia_Pintscher, Snipre, thiemowmde

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T98172: Implement Unit Selector widget

2015-07-20 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T98172 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas, Jc3s5h Cc: Jc3s5h, Jonas, daniel, Aklapper, Snaterlicious, adrianheine, Tobi_WMDE_SW, thiemowmde, Snipre

[Wikidata-bugs] [Maniphest] [Updated] T77982: Decide on implementation of Unit Selector widget

2015-07-20 Thread Jc3s5h
Jc3s5h added a comment. Two questions about https://phabricator.wikimedia.org/P558, unit symbol property: 1. When this is made multilingual, is it possible and desirable to mark it as all languages, which is the case for symbols (but not names) that are included in the International System

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T117031: Represent normalized unit values in full values RDF

2015-10-29 Thread Jc3s5h
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] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF

2015-10-29 Thread Jc3s5h
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&q

[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF

2015-10-29 Thread Jc3s5h
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 rotate

[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF

2015-10-30 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF

2015-10-30 Thread Jc3s5h
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 <h

[Wikidata-bugs] [Maniphest] [Commented On] T117031: Represent normalized unit values in full values RDF

2015-10-30 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-10 Thread Jc3s5h
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 und

[Wikidata-bugs] [Maniphest] [Commented On] T89218: For special precision in Wikidata interface, show dimension in meters

2015-07-08 Thread Jc3s5h
Jc3s5h added a comment. I have added this to Lack of geographic shape data type causing trouble https://www.mediawiki.org/wiki/Talk:Wikibase/DataModel#Lack_of_geographic_shape_data_type_causing_trouble on the data model talk page, since there seems to be disagreement about the conceptual

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T68580: Better support for exact values in Quantity DataType

2015-08-31 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. Herald added a subscriber: Aklapper. TASK DETAIL https://phabricator.wikimedia.org/T68580 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Aklapper, Jc3s5h, Denny, Stryn, Mbch331, Sjoerddebruin

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-08-31 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. 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

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-08-31 Thread Jc3s5h
Jc3s5h added a comment. The discussion of this in //Land Surveyor Reference Manual// 2nd ed., Andrew L. Harbin, Belmont CA: Professional Publications, pp. 1-8 through 1-10 agrees with my own experience. My experience includes creating voltage and current test specifications for mainframe

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T111022: [Story] Improve input for quantities with units

2015-09-01 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T111022 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Lydia_Pintscher, Jonas, Aklapper, Wikidata-bugs, aude, Malyacko

[Wikidata-bugs] [Maniphest] [Commented On] T108808: [Task] Diff for unit changes

2015-09-01 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T108808#1592066, @Mike_Peel wrote, in part: > > If you're taking that approach, you should probably also include an indicator > of the level of significance of the upper/lower bounds. I think the upper and lower bo

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

2015-09-03 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1602377, @daniel wrote in part: > > We could just drop rounding, but that would lead to //false precision// when > applying unit conversion. So we could apply rounding only if we do conversion > - but that w

[Wikidata-bugs] [Maniphest] [Commented On] T111111: [RFC] Wikibase should specify the significance level of lowerBound and upperBound

2015-09-02 Thread Jc3s5h
Jc3s5h added a comment. Consider an example, the mass of an electron: 9.109 383 56 x 10⁻³¹ kg ±0.000 000 11 x 10 x 10⁻³¹ kg where the uncertainty is ± one standard deviation. If we pretend that units had been implemented already, how would this be expressed in the database? The example comes

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

2015-09-04 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1606173, @thiemowmde wrote in part: > Proof of concept: https://github.com/DataValues/Number/pull/43 I don't fully understand this example, but I did notice all the examples seem to provide displayed uncertaint

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

2015-09-03 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1602763, @daniel wrote in part: > @thiemowmde for the same reason 1964 with the precision set to century will > be rendered as 20th century, not 1964+/-50. If you want a solution to be analogous to the way time is h

[Wikidata-bugs] [Maniphest] [Updated] T95425: [Bug] Quantity formatter rounding causes significant data loss

2015-09-03 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1603371, @daniel wrote: > @Jc3s5h I don't see how any of the differences you mention are relevant in > the context of precision/uncertainty. Let me give you another example. If you put in a measurement of 725, i

[Wikidata-bugs] [Maniphest] [Commented On] T89246: Correct and update documentation for Time in DataModel description on mediawiki.org

2015-09-07 Thread Jc3s5h
Jc3s5h added a comment. If we want to make the documentation match the way people have actually been using Time, we should explain that if //after// and //before// are both set to 0, the event occurred some time during the period designated by truncating the time in accord with the //precision

[Wikidata-bugs] [Maniphest] [Commented On] T89246: Correct and update documentation for Time in DataModel description on mediawiki.org

2015-09-07 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T89246#1614220, @thiemowmde wrote in part: > Before = 0, after = 0 does not mean +/-0. Who said that? Obviously the first time a person reads the data model, the person will interpret it in the context of previous experie

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T92365: [Story] Centralize Wikibase documentation process and assign responsibilities

2015-09-01 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T92365 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Tobi_WMDE_SW, JeroenDeDauw, Abraham, Snaterlicious, Aklapper, Wikidata-bugs, aude, Malyacko

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T75604: [Story] create documentation of php data model

2015-09-01 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. TASK DETAIL https://phabricator.wikimedia.org/T75604 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: Jc3s5h, Jonas, Aklapper, Abraham, Tobi_WMDE_SW, thiemowmde, aude, adrianheine, Snaterlicious

[Wikidata-bugs] [Maniphest] [Updated] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-03 Thread Jc3s5h
Jc3s5h added a comment. I think a few terms need to be corrected. Looking at the Wikidata Sandbox, which currently contains the numeric value 724.920±0.001 This is rendered in JSON as {"mainsnak":{"snaktype":"value","property":"https://phabric

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity rounding causes data loss when editing

2015-09-03 Thread Jc3s5h
Jc3s5h added a subscriber: Jc3s5h. Jc3s5h added a comment. One of the issues brought up is data loss. The normal method of converting units does indeed cause data loss: 5 yards +- 1 yard would typically be converted to 5 meters +- 1 meter. As I understand it, unit conversion is not yet

[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

2015-09-15 Thread Jc3s5h
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 i

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-16 Thread Jc3s5h
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; whe

[Wikidata-bugs] [Maniphest] [Updated] T107870: Illegal dates in date type

2015-09-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T107870: Illegal dates in date type

2015-09-11 Thread Jc3s5h
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] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T99674: Decide on internal representation of (Gregorian and Julian) dates with negative years

2015-09-17 Thread Jc3s5h
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, &g

  1   2   >