Page MenuHomePhabricator

[Bug] Entering times used to be blocked with "not supported" but is not any more
Open, NormalPublic

Description

When adding

1 1 1 1:1

to a time property field the save button gets enabled.
When clicking the save button an error occurs

Malformed input: 
+0001-01-01T01:01:00Z

This broke an existing browser test. The old behavior (the error message "Precision higher than "DAY" is not yet supported" was shown during input) should be restored.

Event Timeline

WMDE-Fisch raised the priority of this task from to Needs Triage.
WMDE-Fisch updated the task description. (Show Details)
WMDE-Fisch added a subscriber: WMDE-Fisch.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 18 2015, 9:40 AM

At the moment I can't reproduce this on wikidata.org. But I can reproduce it on my local master.

This behavior is "correct" from a certain perspective. The example date can be parsed by PhpDateTimeParser. This is what you see in the preview. There is no validation involved. The validation in ValidatorBuilders::buildTimeValidators is only applied on save, not during parsing and formatting. Is this a "missing feature" we want to implement?

Jc3s5h added a subscriber: Jc3s5h.Jun 21 2015, 7:01 PM

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 interface is it does not provide for a time zone input. Vast numbers of events are recorded with both a place, and a date. Pretending that a day in Boston is the same as a day in London is just false.

https://github.com/wmde/WikidataBrowserTests/pull/77

@Jc3s5h, please focus on a single issue per ticket. This helps the developers team a lot to stay focused. Thanks.

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 we see the time zone information is truncated and the time is silently changed from the east coast of the US to Greenwich.

I reject the comment "please focus on a single issue per ticket. This helps the developers team a lot to stay focused. Thanks." Until I know whether an actual solution will be proposed, or merely a small step that might lead eventually to a solution, I can't discern the boundaries of the issue for this ticket.

If you found an issue and want to help us solve it then please fill a ticket, describe the steps to reproduce, what output you get and what output you expect. Adding your findings to unrelated tickets isn't going to do anything. I will happily continue to work on time related stuff, but if you start "rejecting" my comments you should be aware that there might be a tendency of me doing the same. Let's stay friends, please.

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 allowed, and disallow saving of what is not allowed. The UI fails to make accessible to the user what is allowed, thus the UI fails because the correct behavior is undefined. This bug cannot be resolved until the correct behavior is defined. "Correct" most likely will turn out to not mean "adequate to represent the things Wikidata wants to represent" but rather "coexists with the rest of the system at this point in the development process".

thiemowmde renamed this task from Wikidata time type properties allow adding a time in the UI but backend checks reject it to Entering times used to be blocked with "not supported" but is not any more.Jun 23 2015, 1:08 PM
thiemowmde updated the task description. (Show Details)
Lydia_Pintscher triaged this task as High priority.Jun 24 2015, 10:44 AM
Lydia_Pintscher moved this task from incoming to consider for next sprint on the Wikidata board.

As the fix is not immediate, lets skip/disable this browsertest for now.

Jonas renamed this task from Entering times used to be blocked with "not supported" but is not any more to [Bug] Entering times used to be blocked with "not supported" but is not any more.Aug 13 2015, 3:30 PM

Err that was the wrong task.

adrianheine lowered the priority of this task from High to Low.Mar 17 2016, 10:45 AM
adrianheine added a subscriber: adrianheine.

This doesn't seem high priority. Actually, I'm not sure we want to fix this at all.

Lydia_Pintscher raised the priority of this task from Low to Normal.Mar 21 2016, 4:54 PM

Until we have proper support for hours/minutes/seconds we should restore the old behavior I'd say.

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

Obama was born on August 4, 1961, at Kapiʻolani Maternity & Gynecological Hospital (now Kapiʻolani Medical Center for Women and Children) in Honolulu, Hawaii; he is the first President to have been born in Hawaii.

is understood to be a statement with precision "day". The Hawaii time zone is understood to be part of the day. By saying the time zone must be set to zero, together with the nearly universal practice of copying whatever the source says into Wikidata, the defacto minimum precision on Wikidata is two days, not one day.