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 cal
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
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
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
ex
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 abou
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 witho
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
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, thi
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
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
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 stan
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
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
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
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
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
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
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
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,
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 Wik
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
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
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
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 i
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
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,
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 zo
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 ha
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 t
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
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
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 dura
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
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
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
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
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 da
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
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
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
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
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
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
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
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 erro
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
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
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
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
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
Jc3s5h added a comment.
In T105100#2647800, @Esc3300 wrote:
If you limit Gregorian before 1584 (or 1582) to precision > 9, do you get comparable numbers?
That being said, many of the years marked as Gregorian on https://tools.wmflabs.org/reasonator/?q=Q208233&lang=en seem to be off by o
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
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
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
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'
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 tweak
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
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
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 o
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
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&#
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
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
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
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
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 kno
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
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
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
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
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 t
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
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
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" clearl
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
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
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
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
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 t
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
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
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
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
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
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
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
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
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 (apparentl
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
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
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?
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 actu
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,
> la
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
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
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T98194#1641408, @thiemowmde wrote:
> The relevant YearMonthDayTimeParser (see
> https://github.com/DataValues/Time/blob/master/src/ValueParsers/YearMonthDayTimeParser.php)
> that could fix this and quite a lot similar
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
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
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
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
1 - 100 of 201 matches
Mail list logo
