[Wikidata-bugs] [Maniphest] T196674: Stop using "century" and "millennium" in association with Wikidata datetime data

2021-02-04 Thread Jc3s5h
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 wiki

[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day on Wikidata

2020-11-05 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day on Wikidata

2020-10-25 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day on Wikidata

2020-10-25 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] T57755: Allow time values more precise than day

2020-10-25 Thread Jc3s5h
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.wikime

[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

2020-03-06 Thread Jc3s5h
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,

[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification

2018-10-24 Thread Jc3s5h
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 yo

[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification

2018-10-23 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification

2018-10-23 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T207705: Implement the Extended Date/Time Format Specification

2018-10-23 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Updated] T189746: Have a calendar converter for input dates at wikidata

2018-10-17 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T189746: Have a calendar converter for input dates at wikidata

2018-10-16 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T189746: Have a calendar converter for input dates at wikidata

2018-10-15 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-07-17 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-07-17 Thread Jc3s5h
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 D

[Wikidata-bugs] [Maniphest] [Commented On] T196674: Stop using "century" and "millennium" in association with Wikidata datetime data

2018-07-17 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Edited] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-07-17 Thread Jc3s5h
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 b

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-07-17 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-06-07 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-06-07 Thread Jc3s5h
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" (o

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-06-06 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-06-06 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-06-05 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Block] T87764: Bugs related to time datatype (tracking)

2018-05-30 Thread Jc3s5h
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,

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

2018-05-30 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T57755: allow time values more precise than day

2018-04-29 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T57755: allow time values more precise than day

2018-04-26 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-04-09 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English

2018-03-28 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T145532: HH:MM:SS time in Wikidata (new datatype or display option for quantity datatype?)

2017-12-07 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T112075: [Story] When editing quantities, allow units to be entered directly into the text input field.

2017-07-30 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)

2017-07-24 Thread Jc3s5h
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

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

2017-07-24 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)

2017-07-05 Thread Jc3s5h
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 f

[Wikidata-bugs] [Maniphest] [Commented On] T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)

2017-07-04 Thread Jc3s5h
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 th

[Wikidata-bugs] [Maniphest] [Updated] T73867: wikidata's JS Time input: adding "after" and "before" for range of time

2017-06-28 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T145898: Wikidata time DataType should emit HTML

2017-01-15 Thread Jc3s5h
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 em

[Wikidata-bugs] [Maniphest] [Created] T155062: Allow entry of globe field, and provide display of globe field, for coordinate location in Wikidata

2017-01-10 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T98194: [Bug] Date parser does not allow February 29, 1700 (Julian)

2016-10-12 Thread Jc3s5h
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] [Maniphest] [Reopened] T146356: [Bug] RDF export misses extreme values with day precision

2016-10-07 Thread Jc3s5h
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

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

2016-09-25 Thread Jc3s5h
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

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

2016-09-25 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T146356: [Bug] RDF export misses extreme values with day precision

2016-09-23 Thread Jc3s5h
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

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

2016-09-23 Thread Jc3s5h
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

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

2016-09-23 Thread Jc3s5h
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

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

2016-09-23 Thread Jc3s5h
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

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

2016-09-23 Thread Jc3s5h
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

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

2016-09-22 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Updated] T92996: Figure out how to represent non-Gregorian dates in RDF export

2016-09-14 Thread Jc3s5h
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

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

2016-09-12 Thread Jc3s5h
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 v

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

2016-09-12 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata

2016-08-12 Thread Jc3s5h
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'

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates in Wikidata Query Service as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T142198: [feature request] add option to display BC dates as on Wikidata

2016-08-11 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T129823: BC (Before Christ) times are not correct in wikidata

2016-08-05 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T76859: Allows to input of plain text such as "today" in time edit widget

2016-06-02 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T136544: [Task] Validate timezones and block all timezones other than 0

2016-05-30 Thread Jc3s5h
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. W

[Wikidata-bugs] [Maniphest] [Commented On] T102930: [Bug] Entering times used to be blocked with "not supported" but is not any more

2016-05-30 Thread Jc3s5h
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ʻol

[Wikidata-bugs] [Maniphest] [Commented On] T127950: Support celestial coordinates

2016-03-20 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Edited] T127950: Support celestial coordinates

2016-03-19 Thread Jc3s5h
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] [Maniphest] [Edited] T127950: Support celestial coordinates

2016-03-18 Thread Jc3s5h
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] [Maniphest] [Commented On] T106923: [Task] add phpt testcases to prove reports regarding bugs in PHP calendar conversion function for julian date and day

2016-03-09 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T127950: Support celestial coordinates

2016-03-04 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Edited] T127950: Support celestial coordinates

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

2016-02-22 Thread Jc3s5h
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

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

2016-02-20 Thread Jc3s5h
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

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

2016-02-20 Thread Jc3s5h
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

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

2016-02-19 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Commented On] T89005: [Story] JSON should (optionally) contain expanded/normalized values.

2016-02-18 Thread Jc3s5h
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 conversio

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T59930: Representation of time inside TimeValue objects should depend on the calendar model

2016-02-18 Thread Jc3s5h
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

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T57755: allow time values more precise than day

2016-02-14 Thread Jc3s5h
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

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

2015-12-04 Thread Jc3s5h
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

[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] [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] 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] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

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

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

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

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

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

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

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

[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

[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] 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] [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] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

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

[Wikidata-bugs] [Maniphest] [Commented On] T112247: [RFC] Create a "number" datatype for exact values

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

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

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

[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

  1   2   >