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 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 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 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 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#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.
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#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.
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 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 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 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 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.
In https://phabricator.wikimedia.org/T105623#1623500, @Jc3s5h wrote:
> If the least significant digit is m time ten to the nth power, I would set
> the default uncertainty to 5 times ten to the nth power, which is the
> greatest uncertainty that might appl
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
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.
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 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.
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.
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.
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.
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.
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/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#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#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.
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 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.
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 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.
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.
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.
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 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 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.
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.
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.
@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.
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.
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.
@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.
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.
@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.
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.
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 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.
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#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#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 https://phabricator.wikimedia.org/T99674#1311361, @Smalyshev wrote:
> > Before the implementation of time zones, this is the longitude of the place
> > of the event, expressed in the range −180° to 180° (positive is east of
> > Greenwich), multipli
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T99674#1311443, @Smalyshev wrote:
> > the date and time of Abraham Lincoln's birth is +1809-02-12T05:42:57 plus
> > or minus one second.
>
>
> Why would anybody do this, given that a) we have precision and
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
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 th
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
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
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
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
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
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T59930
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, daniel, aude
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T67253
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, Wikidata-bugs, thiemowmde, Lydia_Pintscher, daniel, aude, Malyacko,
P.Copp
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
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
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
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 inte
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?ti
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 al
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 that
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 breaka
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
Jc3s5h added a comment.
If you're going to do comparisons and queries on the basis of the stored date,
and ignore precision, before, and after, then the results are going to be
rough. Given that comparisons and queries are inevitably inaccurate, why not
obey the data model and convert y
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
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
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
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
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 Internatio
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
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
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 or
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 m
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 the
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 Gre
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_superscript
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-de
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 i
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 prev
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
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
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
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
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
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
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
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 low
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
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
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
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
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
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
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
1 - 100 of 201 matches
Mail list logo
