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.
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
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 experience.
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
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T95425#1606173, @thiemowmde wrote in part:
> Proof of concept: https://github.com/DataValues/Number/pull/43
I don't fully understand this example, but I did notice all the examples seem
to provide displayed uncertainties tha
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T95425#1603371, @daniel wrote:
> @Jc3s5h I don't see how any of the differences you mention are relevant in
> the context of precision/uncertainty.
Let me give you another example. If you put in a measurement of 725, it g
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
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.
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 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.
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.
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 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 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/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.
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/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 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/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.
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 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 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/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#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#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 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.
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.
{{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.
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 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 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 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/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 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 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.
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.
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 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.
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 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.
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.
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 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.
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.
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.
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/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 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/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/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/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 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/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 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 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/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#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 reply to Rical' comment of Sun, May 24, 08:41 the current documentation is
at https://www.mediawiki.org/wiki/Wikibase/DataModel and
https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON
I understand that the before and after fields were intended, when a da
Jc3s5h added a comment.
To get things moving, I'll make a proposal.
1. The following fields from the internal representation (as shown in JSON) are
essential to correctly interpret a "time" datatype: "time", "timezone",
"precision", and "calend
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T99795
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, Smalyshev, Aklapper, daniel, jkroll, Wikidata-bugs, Jdouglas, aude,
Manybubbles, JanZerebecki
Jc3s5h added a comment.
Am I correct to think that this ticket is **only** about how to represent 1 BCE
in RDF. Thus, the fact that RDF is strictly (possibly proleptic) Gregorian
while Wikidata also supports Gregorian is outside the scope of this ticket, so
conversion between Gregorian and
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T94539#1298906, @daniel wrote:
> @Jc3s5h XSD is always Gregorian, but the question is which year numbering
> should be used in the output. This is regardless of whether the date is
> Gregorian or Julian internally. It&#
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T94539#1298550, @daniel wrote:
> @Smalyshev is it correct to say that at the moment, Julian dates are
> converted to XSD 1.1 dates, but Gregorian dates stay XSD 1.0 in our output? I
> think we should have an option for swit
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T59704
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, Wikidata-bugs, thiemowmde, Micru, adrianheine, Snaterlicious,
Lydia_Pintscher, daniel, aude
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T94064#1296543, @daniel wrote:
> @mkroetzsch precise dates for prehistoric times may be useful for
> astronomical events. These could/should use a different calendar model
> though, such as https://en.wikipedia.org/wiki/J
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T99674
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, daniel, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu,
Addshore, Liuxinyu970226
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T94064#1158423, @mkroetzsch wrote in part:
> Julian day calculation is a very simple algorithm
> (https://en.wikipedia.org/wiki/Julian_day#Calculation), and this is all you
> need for date comparisons, calendar conversion,
Jc3s5h added a comment.
As far as I can tell Wikidata's statement to data contributors and users about
the meaning of dates stored in Wikidata is at [[mw:Wikibase/DataModel/JSON]].
The [ earliest version] dated 29 April 2014 states "time: Date and time in ISO
notation". The 2004
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T94539
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc: Jc3s5h, JanZerebecki, Manybubbles, Thompsonbry.systap, Haasepeter,
Beebs.systap, Aklapper, Smalyshev
Jc3s5h added a comment.
ISO 8601:2004_E states
**--calendar year** is, unless specified otherwise, represented by four digits.
Calendar years are numbered in
ascending order according to the Gregorian calendar by values in the range
[] to []. Values in
the range [] through [1582
Jc3s5h added a subscriber: Jc3s5h.
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T85324#996337, @Addshore wrote:
> 2011-4-19 is clearly the 19th of April 2011, so why not parse this too?
Yes, 2014-4-19 is pretty clearly the 19th of April 2011. But the string
"2011-4-
Jc3s5h added a subscriber: Jc3s5h.
Jc3s5h added a comment.
This is described as documentation. But isn't there some part of Wikidata that
parses input and stores it in some unstated format? Isn't there some other part
of Wikidata that parses the stored format and output it in what s
Jc3s5h added a comment.
Looking at the title of this task, "Time-Parser should detect most likely
calendar", I think it should be explicitly stated what time parser(s) this task
will consider; the time parser(s) used to take date input from users who employ
the user interface, the t
Jc3s5h added a comment.
I tested JavaScript:
document.write(new Date( 1900, 1, 29 ).toDateString())
Which gave as a result
Thu Mar 01 1900
So this indicates that the JavaScript Date object is the wrong tool for the job
we are doing. I haven't tested PHP, but that is suspect too. So the
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T85296#973355, @Addshore wrote:
> Okay, so when entering "31 September 1949" through the Frontend in an edit
> and saved it is formatted as "1 October 1949" and correctly saved as
> "+019
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T85296
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T72395#1088223, @Conny wrote:
> Do not know right position. User mentioned that it makes no sense to declare
> dates as gregorian before calendar reform.
ISO 8601 uses the (possibly proleptic) Gregorian calendar for all dates
Jc3s5h added a comment.
In response to thiemowmde's post of Mon., Feb. 23, 17:21, I suggest that rather
than marking //calendartime// obsolete, we mark it reserved for support of
calendars other than proleptic Gregorian and proleptic Julian, with no usage
rules decided upon yet.
TASK D
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T88438#1059026, @thiemowmde wrote:
> > only consider parsers and validators known to the development team.
>
>
> I'm describing what the development team decided, what's currently in the
> database and wha
Jc3s5h added a comment.
thiemowmde's comment of Monday, Feb. 23, 11:07 seems to only consider parsers
and validators known to the development team. Maybe it's a fact that no one has
ever written a good ISO 8601 parser or validator that can process years with
more than 4 digits; I
Jc3s5h added a comment.
The code comment state above does not constitute a decision. I don't know if
this project allows important decisions to be made without discussion and
hidden in code comments. Even if that is allowed, there is still no decision.
There is only a general conce
Jc3s5h added a comment.
Releasing fixes ASAP before deciding how dates should be stored seems like
putting the cart before the horse, unless you plan to release an additional
patch later after we decide how to store dates.
TASK DETAIL
https://phabricator.wikimedia.org/T88438
REPLY HANDLER
Jc3s5h added a comment.
Please see my proposed ISO 8601 profile for Wikidata
<https://www.wikidata.org/wiki/User:Jc3s5h/ISO_8601_profile_for_Wikidata>. I
believe the points in that user page need to be addressed, even if we decide on
a different result than I propose.
TASK DETAIL
Jc3s5h added a comment.
I have created a proposal on Wikidata at
https://www.wikidata.org/wiki/User:Jc3s5h/ISO_8601_profile_for_Wikidata
Unless I forgot something, I believe it covers the points that need to be
specified in order to understand a date outside the context of a particular
Jc3s5h added a comment.
I note thiemowmde's patch for review at Feb 6, 16:32 says what we are doing now
is:
//* URI identifying the calendar model. The actual time value should be in this
calendar model,
- but note that there is nothing this class can do to enforce this convention.//
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T88438
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To
Jc3s5h added a comment.
I would add to Addshore's comment that ordinarily dates of death and birth
should be considered local time; usually there will not be sufficient
information to convert to a date that begins and ends at midnight universal
time.
TASK DETAIL
Jc3s5h added a comment.
I wish to point out this edit:
https://www.wikidata.org/w/index.php?title=Q692&diff=193453963&oldid=193042089
It creates a timestamp +0001564-00-00T00:00:00Z
But of course month 0 and day 0 are not valid ISO 8601 values. The proper ISO
8601 representation o
Jc3s5h added a comment.
In response to Candalua's comment, consider that the Julian calendar was used
in Europe. Outside Europe, some countries converted directly from a calendar
that was neither Gregorian nor Julian to Gregorian. The Julian-to-Gregorian
switch occurred at many different
Jc3s5h added a comment.
Documentation says dates are represented in conformance with ISO 8601, with a
fixed 11 digits for the year. ISO 8601 requires that all dates be expressed in
the Gregorian calendar. We have no format defined to store a Julian calendar
date. Considering that the authors
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T87312#998321, @JulesWinnfield-hu wrote:
> Please take into consideration that 10 June 323 BC, Julian is ISO
> **−322-06-05** because of ISO year 0.
Strictly speaking, 10 June 323 BC, Julian is ISO 8601:2004 -0322-06-05 becaus
Jc3s5h added a comment.
As for
> The +0019 example is irrelevant for what we do.
It is somewhat relevant because the data consumer may be using a pre-written
ISO 8601 parser that supports +0019 as a century for year length 6, and must
know the year length in order to do so. If we emit d
Jc3s5h added a comment.
ISO 8601 says "The interchange parties shall agree the additional number of
digits in the time element year." I believe thiemowmde is incorrect in claiming
that this can mean the data exchange partners can agree to a variable number of
digits.
Other pa
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T66084#996435, @thiemowmde wrote:
> Uh, what? What about fixing the documentation? It's marked as //"This
> document is a draft, and should not be assumed to represent the ultimate
> structure"// anyway.
>
Jc3s5h added a comment.
In reply to thiemowmde, P570 (Date of death; the same argument applies to P569,
Date of birth) |has datatype TimeValue. The description of the datatype is at
https://www.mediawiki.org/wiki/Wikibase/DataModel. The first element the
TimeValue structure is described as
Jc3s5h added a comment.
I am unable to find any tool that promises to return the data in exactly the
form it is stored in the Wikidata database. I did find one method of displaying
the contents of an item; an example of the url is
https://www.wikidata.org/wiki/Special:EntityData/Q692.json
Jc3s5h added a comment.
In light of Addshore's comment of January 26, 2015, 23:12, I would say that a
bot must be created to change every date so the year contains exactly 16
digits, and every date with a different number of digits is invalid.
TASK DETAIL
https://phabricator.wikimedi
Jc3s5h added a comment.
ISO 8601:2000 contains the following requirement:
"If, by agreement, expanded representations are used, the formats shall be as
specified below. The
interchange parties shall agree the additional number of digits in the time
element year. In the examples below
i
Jc3s5h added a subscriber: Jc3s5h.
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jc3s5h
Cc
Jc3s5h added a comment.
In reply to Lydia_Pintscher:
I enter "Galileo in search box.
A dropdown appears and I click "Galileo Galilei". The item page for Galileo
Galilei (Q307) appears.
I scroll down to "date of birth". The box reads:
"date of birth 25 Februa
101 - 200 of 201 matches
Mail list logo
