Page MenuHomePhabricator

Jc3s5h (Gerry Ashton)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Oct 30 2014, 2:04 PM (238 w, 2 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Jc3s5h [ Global Accounts ]

Recent Activity

Oct 24 2018

Jc3s5h added a comment to T207705: Implement the Extended Date/Time Format Specification.

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 you can read at the linked page: "the EDTF specification is included as a profile of ISO 8601."

Oct 24 2018, 4:24 PM · Wikidata

Oct 23 2018

Jc3s5h added a comment to T207705: Implement the Extended Date/Time Format Specification.

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.

Oct 23 2018, 10:44 PM · Wikidata
Jc3s5h added a comment to T207705: Implement the Extended Date/Time Format Specification.

@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 set by external organizations and we lack the ability to change them.

Oct 23 2018, 6:41 PM · Wikidata
Jc3s5h added a comment to T207705: Implement the Extended Date/Time Format Specification.

This specification is a non-starter because Wikidata supports both the Gregorian and Julian calendar while this spec only supports the Gregorian calendar.

Oct 23 2018, 3:22 PM · Wikidata

Oct 17 2018

Jc3s5h added a comment to T189746: Have a calendar converter for input dates at wikidata.

@Huji The task description talks about inputting data, not reading data that is already present.

Oct 17 2018, 2:55 PM · Wikidata, MediaWiki-extensions-WikibaseClient, Wikidata-Gadgets

Oct 16 2018

Jc3s5h added a comment to T189746: Have a calendar converter for input dates at wikidata.

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://php.net/manual/en/datetime.formats.php for the acceptable formats. That page has no mention of non-Gregorian calendar support.

Oct 16 2018, 2:52 PM · Wikidata, MediaWiki-extensions-WikibaseClient, Wikidata-Gadgets
Jc3s5h added a comment to T189746: Have a calendar converter for input dates at wikidata.

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.

Oct 16 2018, 12:47 AM · Wikidata, MediaWiki-extensions-WikibaseClient, Wikidata-Gadgets

Jul 17 2018

Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

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 matter but articles on individual centuries on Wikipedias (I checked English and German ones) list "20th century" as timeperiod between January 1, 1901 and ended on December 31, 2000, and that did not change in last 15 years. It might be counter intuitive and not compatible with some software, but it seems like that is the understanding of the term.

Jul 17 2018, 5:53 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata
Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

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.

Jul 17 2018, 5:50 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata
Jc3s5h added a comment to T196674: Stop using "century" and "millennium" in association with Wikidata datetime data.

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 link to the item like Q6955 to clarify the definition, and where we can specify the date range.

Jul 17 2018, 3:39 PM · Wikidata
Jc3s5h updated the task description for T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.
Jul 17 2018, 3:33 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata
Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

(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 has nonstandard date handling and has slightly different ranges for centuries and millennia.)

Jul 17 2018, 3:28 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Jul 16 2018

Jc3s5h added a comment to T199660: Show name of character in mouseover popup of "insert special character" gadget on English Wikipedia.

One benefit would be to educate editors that the proper characters to indicate arcminutes or arcseconds is not the apostrophe or double quote respectively.

Jul 16 2018, 10:33 AM · Wikimedia-General-or-Unknown

Jun 7 2018

Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

@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.

Jun 7 2018, 8:58 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata
Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

@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" (or if that's too hard, "5 century"). If the word "century" is abandoned, then this bug is moot, but that doesn't mean that this is the right place to talk about accurately representing 100-year ranges.

Jun 7 2018, 11:07 AM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Jun 6 2018

Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

Can y'all please open separate bugs for these other issues and not just dump them all in this bug? Thanks.

Jun 6 2018, 10:17 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata
Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

It looks like y'all are actually discussing T73459, so please feel free to continue there.

Jun 6 2018, 10:05 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Jun 5 2018

Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

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:

Jun 5 2018, 1:24 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

May 30 2018

Jc3s5h reopened T67267: Specify whether TimeValue stores timestamps in UTC or local time. as "Open".

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 always UT. Daniel's statement "the spec is quite clear in saying that the time is indeed local time, always" is a direct contradiction of the spec.

May 30 2018, 1:22 PM · Wikidata, MediaWiki-extensions-WikibaseRepository
Jc3s5h reopened T67267: Specify whether TimeValue stores timestamps in UTC or local time., a subtask of T87764: Bugs related to time datatype (tracking), as Open.
May 30 2018, 1:21 PM · Tracking-Neverending, Wikidata

Apr 29 2018

Jc3s5h added a comment to T57755: Allow time values more precise than day.

@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 have to be modified to accept 11.5 as a float. Not only that, if we start emitting 11 as a float, it will break all the existing emitters. If we emit 11 as an integer and 11.5 as a float, that will complicate consuming software because it will have to be flexible and accept either an integer or a float in that position.

Apr 29 2018, 12:32 PM · Wikidata, MediaWiki-extensions-WikibaseRepository

Apr 26 2018

Jc3s5h added a comment to T57755: Allow time values more precise than day.

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 zone where the event took place, but this was '''falsely''' entered into Wikidata as UTC. The sources generally do not give the time of day of the event, so it is impossible to convert the date in local time to UTC.

Apr 26 2018, 5:03 PM · Wikidata, MediaWiki-extensions-WikibaseRepository

Apr 9 2018

Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

This is being discussed at Help talk:Dates on Wikidata.

Apr 9 2018, 12:42 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Mar 29 2018

Jc3s5h added a comment to T190813: Module for unit conversions.

I'm skeptical about Wikidata considering that it can't get foot right. ( See https://www.wikidata.org/wiki/Q3710 )

Mar 29 2018, 8:49 PM · MediaWiki-extension-requests

Mar 28 2018

Jc3s5h added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

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.

Mar 28 2018, 10:54 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Dec 7 2017

Jc3s5h added a comment to T145532: HH:MM:SS time in Wikidata (new datatype or display option for quantity datatype?) .

Don't forget to include the time zone!

Dec 7 2017, 3:41 PM · DataValues, patch-welcome, MediaWiki-extensions-WikibaseRepository, Wikidata

Sep 3 2017

Jc3s5h created T174887: False classification of .mil sites as dead.
Sep 3 2017, 12:59 PM · InternetArchiveBot

Jul 30 2017

Jc3s5h added a comment to T112075: [Story] When editing quantities, allow units to be entered directly into the text input field..

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, precision and time zone in the future. Which of those should behave the same and which differently?

Gut feeling: I like two fields better because it makes it a bit clearer that you are selecting an existing item for the unit and can't just type anything.

Jul 30 2017, 4:24 PM · Design, WMDE-Design, Story, Wikidata, MediaWiki-extensions-WikibaseRepository

Jul 24 2017

Jc3s5h added a comment to T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).

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 number on, January 1, for bot the Gregorian and Julian calendars.

Jul 24 2017, 2:24 PM · Documentation, Wikibase-DataModel, Wikidata
Jc3s5h added a comment to T67267: Specify whether TimeValue stores timestamps in UTC or local time..

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 other conventions.

Jul 24 2017, 2:21 PM · Wikidata, MediaWiki-extensions-WikibaseRepository

Jul 5 2017

Jc3s5h added a comment to T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).

As a first step, we might just consider that "unused" means "unspecified".

Jul 5 2017, 12:42 PM · Documentation, Wikibase-DataModel, Wikidata
Jc3s5h added a comment to T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).

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 database and change all the existing timezone values to unspecified. Then correct values can be added once the facility to specified them becomes available, and as editors determine which values are correct.

Jul 5 2017, 1:39 AM · Documentation, Wikibase-DataModel, Wikidata

Jun 28 2017

Restricted Application added a project to T73867: wikidata's JS Time input: adding "after" and "before" for range of time: Wikidata.
Jun 28 2017, 3:17 PM · Wikidata, MediaWiki-extensions-WikibaseClient

May 18 2017

Jc3s5h added a comment to T132308: Internationalise citoid dates.
May 18 2017, 4:51 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.
In T132308#3273017, @Mvolz wrote in part:

I have opened up the conversation to the wikicite-discuss group as well: https://groups.google.com/a/wikimedia.org/forum/#!topic/wikicite-discuss/a2kRHayAiyo

May 18 2017, 12:16 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.
In T132308#3273017, @Mvolz wrote in part:

Someone there suggested EDTF (extended date time format) https://www.loc.gov/standards/datetime/ - this looks like exactly what we need.

May 18 2017, 12:00 PM · User-Josve05a, VisualEditor, Citoid

May 17 2017

Jc3s5h added a comment to T132308: Internationalise citoid dates.
May 17 2017, 8:50 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.

|date= already doesn't follow IS0 8601. It has never followed ISO 8601. The decision that |date= would not follow ISO 8601 was made years before citoid was created. I'm not sure why "editor doesn't follow ISO 8601 while typing manually" should be separated from "editor still doesn't follow ISO 8601 while using a semi-automated script".

May 17 2017, 6:21 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.
May 17 2017, 11:47 AM · User-Josve05a, VisualEditor, Citoid

May 16 2017

Jc3s5h added a comment to T132308: Internationalise citoid dates.

|date= already doesn't follow IS0 8601. It has never followed ISO 8601. The decision that |date= would not follow ISO 8601 was made years before citoid was created. I'm not sure why "editor doesn't follow ISO 8601 while typing manually" should be separated from "editor still doesn't follow ISO 8601 while using a semi-automated script".

May 16 2017, 9:00 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.

If you're not going to follow a standard, you should go far away from the standard to avoid confusion. I'd suggest keeping the date and year field just as they are. In the absence of both those fields, the template could look for citoid-month, citoid-year, citoid-day, citoid-season, and whatever else is required.

May 16 2017, 6:59 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.

Lots of tools and bots examine citations. I'm not really sure which ones examine the rendered HTML, which ones examine the COinS metadata, and which ones examine the wikitext. Anything that examines the wikitext and finds yyyy-mm-00 should reject it as completely non-standard.

May 16 2017, 12:46 PM · User-Josve05a, VisualEditor, Citoid

May 14 2017

Jc3s5h created T165242: Changes archive URL for no reason..
May 14 2017, 12:46 PM · InternetArchiveBot (v1.3), Internet-Archive

May 13 2017

Jc3s5h added a comment to T132308: Internationalise citoid dates.

Worth noting that if you try this in wikidata, i.e. "Fall 2003" you will get "date is malformed..." so they haven't figured it out either. Since iso8601 allows ranges, I can imagine us translating say, "Fall 2003" to be Sept-Nov 2003, which would be 200709/200711 instead of having the special formats. And converting Christmas to December 25th :) (which we could actually do right now with the current set-up actually.) And quarter 1 is Jan-March?

May 13 2017, 2:30 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.

Thanks, that's helpful. That suggests that maybe the 00-ed out version that wikidata uses i.e. 2007-05-00 might preferable since there's no way to confuse that with a date range.

May 13 2017, 2:26 PM · User-Josve05a, VisualEditor, Citoid
Jc3s5h added a comment to T132308: Internationalise citoid dates.

The WMF should provide any of its employees working on this an official copy of ISO 8601 and they should be required to read it. Among other things, they would find that the only correct way to represent the current year is "2017". "2017-00" or "2017-00-00" are just wrong. Likewise, the only correct ways to represent the current year and month are "201705" or "2017-05"; "2017-05-00" is wrong.

May 13 2017, 12:02 AM · User-Josve05a, VisualEditor, Citoid

May 12 2017

Jc3s5h added a comment to T165116: If WorldCat has the date recorded as "2007", then please add the date as "2007" instead of "2007-01-01".
In T165116#3257456, @Astinson wrote, in part:
May 12 2017, 3:15 AM · VisualEditor, Citoid

Jan 15 2017

Jc3s5h added a comment to T145898: Wikidata time DataType should emit HTML <time>.

Sounds like another calendar model trap (W3C spec requires Gregorian)

Jan 15 2017, 6:38 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, Wikidata

Jan 10 2017

Jc3s5h created T155062: Allow entry of globe field, and provide display of globe field, for coordinate location in Wikidata .
Jan 10 2017, 10:26 PM · Wikidata

Oct 12 2016

Jc3s5h added a comment to T98194: [Bug] Date parser does not allow February 29, 1700 (Julian).

I offer a list of test cases.

Oct 12 2016, 5:12 PM · Wikidata-Sprint-2016-09-21, Wikidata-Sprint-2015-09-29, Wikidata-Sprint-2015-09-15, MediaWiki-extensions-WikibaseRepository, DataValues, Wikidata

Oct 7 2016

Jc3s5h added a comment to T146356: [Bug] RDF export misses extreme values with day precision.
Oct 7 2016, 4:26 PM · Patch-For-Review, Wikidata-Sprint-2016-09-21, Wikidata-Query-Service, MediaWiki-extensions-WikibaseRepository, Discovery, Wikidata
Jc3s5h reopened T146356: [Bug] RDF export misses extreme values with day precision as "Open".

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 for values that are too large, $jd could be 0, negative, or of the same order of magnitude as the year (when it should be about 365 times the year). Also, for values that are too large, $gregorian might or might not be "0/0/0".

Oct 7 2016, 4:15 PM · Patch-For-Review, Wikidata-Sprint-2016-09-21, Wikidata-Query-Service, MediaWiki-extensions-WikibaseRepository, Discovery, Wikidata
Jc3s5h reopened T146356: [Bug] RDF export misses extreme values with day precision, a subtask of T87764: Bugs related to time datatype (tracking), as Open.
Oct 7 2016, 4:15 PM · Tracking-Neverending, Wikidata

Sep 25 2016

Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.
Sep 25 2016, 12:21 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata
Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

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).
The GUIDS will remain the same throughout changes to the statement, the one exception is when items are merged, where statements are moved from one item id to another.

Sep 25 2016, 12:11 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata

Sep 24 2016

Jc3s5h added a comment to T146356: [Bug] RDF export misses extreme values with day precision.

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 200000BC, really, at least not using Earthly calendars :) handling these errors in more sane manner is good. However, I think we need then to change precision, if we operate under year precision, we can't just take year and then claim day precision. It'd be claiming false data.

Sep 24 2016, 12:59 AM · Patch-For-Review, Wikidata-Sprint-2016-09-21, Wikidata-Query-Service, MediaWiki-extensions-WikibaseRepository, Discovery, Wikidata

Sep 23 2016

Jc3s5h added a comment to T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).

I have made a parallel request at the mediawiki talk page for Wikibase/Indexing/RDF_Dump_Format. There is no mention there of needing to submit a Phabricator ticket to change that documentation.

Sep 23 2016, 8:52 PM · Documentation, Wikibase-DataModel, Wikidata
Jc3s5h updated the task description for T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).
Sep 23 2016, 8:44 PM · Documentation, Wikibase-DataModel, Wikidata
Jc3s5h created T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).
Sep 23 2016, 8:43 PM · Documentation, Wikibase-DataModel, Wikidata
Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

@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 that we can avoid!

Sep 23 2016, 8:07 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata
Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

@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 that we can avoid!

Sep 23 2016, 7:45 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata
Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

The bot followed this tree up to the first level, at which point human intervention is needed.

@Multichill the two edits edits that you have linked appear to be for statements that have no references. Per the decision tree we should try and find references for these to ensure they are correct.

Sep 23 2016, 6:42 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata
Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

@Addshore asked for some examples of off-by-one years where the year is less than one.

Sep 23 2016, 2:33 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata

Sep 22 2016

Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

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?

Sep 22 2016, 3:12 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata

Sep 19 2016

Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

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 one year.
Unfortunatly not all. For years before year 1, probably all of them.

Maybe a special check for anything before year 1 is needed.

Sep 19 2016, 1:35 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata

Sep 14 2016

Restricted Application added a project to T92996: Figure out how to represent non-Gregorian dates in RDF export: Discovery.
Sep 14 2016, 6:57 PM · Discovery, Patch-For-Review, Wikidata-Query-Service, Wikidata

Sep 12 2016

Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

Thanks to Addshore for the answer of Sep. 12, 17:54 UT.

Sep 12 2016, 10:50 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata
Jc3s5h added a comment to T105100: [Task] Run bot to mark dates that need checking for calendar model correctness.

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 that produces the rdf was able to convert the date from Julian to Gregorian or not. Such irregularities might cause some dates that should be marked to be missed.

Sep 12 2016, 4:48 PM · WMDE-QWERTY-Team-Experimental-Sprint, Wikidata-Sprint-2016-08-02, User-Addshore, Wikidata.org, Wikidata

Aug 11 2016

Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

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 are still needed to make various parts reject or vilify dates they consider invalid, but this is a big step forward.

Aug 11 2016, 7:45 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.
Aug 11 2016, 6:36 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.
Aug 11 2016, 6:29 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

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 of the RDF format (at least one of :) and I am not aware of any "controversy" - RDF follows XSD 1.1, and it's the industry standard. If you have observed some bugs there please submit a ticket.

But of course the converter can't be written until the notation used in the source the converter is receiving input from is known with certainty.

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 *something* in the output, and by the fact of putting that into output we are defining our interpretation.

Right now the dates in the DB and JSON follow (roughly) the XSD 1.0 standard for serializing dates, but the RDF follows XSD 1.1 since it is accepted standard in semantic data world.

The last date - 0000-01-30 - doesn't seem to be valid, i.e. it does not describe any actual point on the date scale. Wikibase may sometimes allow to enter nonsensical values (including February 30th, etc.), but RDF can not really represent it.

Aug 11 2016, 6:18 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

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 seriously question the decision of the UI authors to make fussy decisions about when to display the calendar and when not to. I think it would be better, and more resilient to any changes in this area in the UI, to always display the calendar.

Aug 11 2016, 5:51 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

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 0000-01-22 while taking the default for this, Julian calendar, so I'm ignoring that date.) The diff column is the timestamp value one sees while viewing diffs between different versions of the sandbox.

Aug 11 2016, 4:41 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

Oh dear. Blazegraph recently went through an upheaval, switching from XSD 1.0 (where year 0000 does not exist and -0002 = 2 BCE) to XSD 1.1 (where year 0000 does exist and -0001 = 2 BCE). 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.

Aug 11 2016, 3:22 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

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't care whether AD/BC are used vs. CE/BCE.

Aug 11 2016, 2:15 PM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery
Jc3s5h added a comment to T142198: [Task] Make display of BCE dates in Wikidata Query Service identical to Wikidata.

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 variety of tools, not just the user interface. There is reason to suspect some of these tools would have treated -0001-01-01 as January 1, 2 BCE, while others would have treated it as January 1, 1 BCE. Thus, looking at examples of well-known BCE dates in the user interface is not a reliable way to judge the definition of the source of data that the user interface pulls from.

Aug 11 2016, 10:08 AM · Patch-For-Review, Wikidata-Sprint-2016-08-16, Wikidata-Query-Service, Wikidata, Discovery

Aug 5 2016

Jc3s5h added a comment to T129823: BC (Before Christ) times are not correct in wikidata.

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 indicate they follow astronomical year numbering, and also ISO 8601 2004 edition, and acknowledge the existence of a year 0, so those formats should give the year as -7. If we use this url:

Aug 5 2016, 12:41 PM · Discovery, Wikidata-Query-Service, Wikidata

Jun 2 2016

Restricted Application updated subscribers of T76859: Allows to input of plain text such as "today" in time edit widget.
Jun 2 2016, 1:06 PM · DataValues, patch-welcome, Wikidata, MediaWiki-extensions-WikibaseRepository

May 30 2016

Jc3s5h added a comment to T136544: [Task] Validate timezones and block all timezones other than 0.

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 tells us Barack Obama was born August 4, 1961 in Hawaii. We know that Hawaii standard time is 10 hours behind UT, and Hawaii does not observe daylight time. We can safely conclude Obama was born between 04:00 August 3 and 14:00 August 4, UT. Providing the ability to input a correct time zone allows the information from most statements in sources about births and deaths to be faithfully reproduced.

May 30 2016, 12:16 PM · MediaWiki-extensions-WikibaseRepository, Wikidata
Jc3s5h added a comment to T102930: [Bug] Entering times used to be blocked with "not supported" but is not any more.

The addition of the blocking task T136544: [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

May 30 2016, 12:06 PM · DataValues, MediaWiki-extensions-WikibaseRepository, Wikidata

Mar 17 2016

Jc3s5h updated the task description for T127950: [Story] Support celestial coordinates.
Mar 17 2016, 9:16 PM · Story, Wikidata
Jc3s5h added a comment to T127950: [Story] Support celestial coordinates.

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, quasars, pulsars, galaxies, and the like. The kind of objects and the kind of data available for them can be explored at the US Naval Observatory's NOMAD catalog.

Mar 17 2016, 9:14 PM · Story, Wikidata
Jc3s5h updated the task description for T127950: [Story] Support celestial coordinates.
Mar 17 2016, 9:07 PM · Story, Wikidata

Mar 9 2016

Jc3s5h added a comment to T106923: [Task] add phpt testcases to prove reports regarding bugs in PHP calendar conversion function for julian date and day.

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, particularly since calendar programming is full of integer division and modulo operations that depend on the exact behavior of these functions, including how they work with negative numbers.

Mar 9 2016, 3:10 PM · MediaWiki-extensions-WikibaseRepository, patch-welcome, Wikidata

Mar 4 2016

Jc3s5h added a comment to T127950: [Story] Support celestial coordinates.

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 angle. I suggest it should not be a goal of this support to allow a round-trip conversion, but rather, to approximate the precision of the source in the manner usually followed by engineers and scientists. For example, if a source gave a R.A. as 3h 10m, but the implementors decided to store it as decimal hours, it should be stored as 3.17 h to reflect the precision of the source, not as 3.16666666666667 h or the like. If a data consumer were to convert 3.17 h back to h m s, he/she would get 3 h 10 m 12 s, and the responsibility would be on the data consumer to realize that the value was only given to three significant figures and so 3 h 10 m 12 s should be rounded to 3 h 10 m.

Mar 4 2016, 3:23 PM · Story, Wikidata
Jc3s5h updated the task description for T127950: [Story] Support celestial coordinates.
Mar 4 2016, 3:07 PM · Story, Wikidata

Feb 22 2016

Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

We are currently using XSD 1.1 format in both cases, and in both cases the date is (proleptic) Gregorian.

Feb 22 2016, 2:32 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata

Feb 20 2016

Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

For the name 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?

Feb 20 2016, 6:35 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata
Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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 second.

Feb 20 2016, 12:12 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata

Feb 19 2016

Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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 00000002016-02-26. Doing otherwise would force data consumers to check their ISO 8601 parsing software to see if it can handle our violations.

Feb 19 2016, 11:56 AM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata

Feb 18 2016

Jc3s5h added a comment to T89005: [Story] JSON should (optionally) contain expanded/normalized values..

The task description should be modified thus:

Feb 18 2016, 4:11 PM · Story, Wikidata
Restricted Application updated subscribers of T59930: Representation of time inside TimeValue objects should depend on the calendar model.

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 close to 0° longitude, because they all say that the event occurred in a certain date time zone 0. I have not seriously begun correcting birth or death dates because Wikidata is currently incapable of storing the correct values.

Feb 18 2016, 3:53 PM · Wikidata, MediaWiki-extensions-WikibaseRepository

Dec 21 2015

Jc3s5h created T122071: Guarantee valid dates.
Dec 21 2015, 7:56 PM · VisualEditor, Citoid

Dec 4 2015

Jc3s5h updated the task description for T59704: Support Julian Date (astronomy).
Dec 4 2015, 8:30 PM · Wikidata, patch-welcome, MediaWiki-extensions-WikibaseRepository

Oct 30 2015

Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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) a "fierce debate" at the World Radiocommunication Conference in November. Treating an international organization's standard as atomic-based when it is really rotation-based becomes more serious during a time when a "fierce debate" is raging.

Oct 30 2015, 11:20 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata
Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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 to limit values to those that fall within the range of validity of the Gregorian calendar (the exact limits are not obvious) and a different data type created for dates in the far distant past or future, or we should stop naming or implying any external standard and acknowledge its something we made up ourselves, unrelated to ISO or the World Wide Web Consortium. It is not honest to knowingly ascribe to others statements that we know they did not make, such as the possibility of expressing the age of the universe in a notation that conforms to an ISO or W3C standard.

Oct 30 2015, 9:53 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata
Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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 deserve to be defunded. STOP WRITING ISO UNLESS YOU REALLY MEAN IT AND INTEND TO ABIDE BY EVERY SINGLE RULE IN THE SPEC.

Oct 30 2015, 5:02 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata

Oct 29 2015

Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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 its axis, which was much later (around 4,540 million years ago, measured in constant length seconds). So the date stated for the start of the universe in wikidata is false because the calendar was undefined and beyond any plausible extrapolation procedure at the time of the event.

Oct 29 2015, 4:50 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata
Jc3s5h added a comment to T117031: Represent normalized unit values in full values RDF.

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-00T00:00:00Z"?

Oct 29 2015, 3:45 PM · Patch-For-Review, Discovery-Wikidata-Query-Service-Sprint, Wikidata-Query-Service, Discovery, Wikidata