Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

DataValue Time recognizes the ISO date value not very well in Korean language.
Closed, ResolvedPublic

Description

When the interface language is set to Korean, DataValue Time parser often does not recognize the ISO date properly.

Case 1: Recognizes the complete ISO date format (YYYY-mm-dd) as invalid date format
I was trying to edit [[d:Q7318]] to add start dates of head of state. I tried to add the start date "1934-08-02" and returned "invalid date format" message. "1934-08" returns Aug. 1934, but "1934-08-02" returned "invalid date format".

Case 2: Recognizes the 1st of month even the input is entered for other date.
When the date value is entered as "1773-12-16", the parser recognizes the date as "1776-12-01". When I entered the value "2014-10-04", the parser recognized "2014-10-01". You can find the case at https://www.wikidata.org/w/index.php?title=Q495366&action=history and https://www.wikidata.org/w/index.php?title=Q19024&action=history

Event Timeline

Kwj2772 raised the priority of this task from to High.
Kwj2772 updated the task description. (Show Details)
Kwj2772 added a project: DataValues.
Kwj2772 subscribed.
Lydia_Pintscher lowered the priority of this task from High to Medium.Dec 27 2014, 11:37 AM
Lydia_Pintscher added a project: Wikidata.
Lydia_Pintscher set Security to None.
revi raised the priority of this task from Medium to High.Jan 24 2015, 1:30 PM

Now I cannot save "Birth date" property, with error "Unknown API error".

PS. I've seen this since December 2014 or earlier...

@Addshore On 3rd sandbox, "Birth date" property and date: 1999-12-31.

Now I tried to add P571 as 2011-04-19 (19th Apri, 2011) to this item, and result says "2004-11-20 (20th November, 2004)". Diff When I appened ?uselang=en on URL, it worked well, Diff

Note that "2011-04-19" is not a valid ISO timestamp our current parser setup can recognize as an ISO timestamp. It must be "+2011-04-19T00:00:00Z" to be recognized as such.

"2011-04-19" is recognized as, well, something very odd by PHP's build in DateTime parser (see http://php.net/manual/en/datetime.construct.php). We are using this as a fallback. There is nothing we can do to "fix" that part of PHP other than implement our own parsers.

I uploaded https://github.com/DataValues/Time/pull/27. It rewrites our existing parser in a way it can recognize incomplete ISO date strings. Note that strings like "2011-4-19" will still be invalid with this patch.

2011-4-19 is clearly the 19th of April 2011, so why not parse this too?

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-19" does not follow any standard, it is just a format invented by some use on some occasion. So at some undefined point in the past, the meaning becomes unclear. The new parser would have to contain some date to divide between clear dates, which would be accepted, and unclear dates, which would be rejected. What should that date be? Perhaps 1 March 1923, which is, I believe, the last date a country changed from the combination of the Julian calendar and AD/BC year notation to the Gregorian calendar and AD/BC year notation. Other countries have changed since, but the preceding calendar either wasn't Julian or didn't use AD/BC year notation.

thiemowmde claimed this task.

All examples given in the tickets description do work now on wikidata.org.

The case "2011-4-19" with missing leading zeros is out of the scope of this ticket, as argued above. If this feature is really needed it should have it's own ticket.