Yes, I knew EDTF, it came up in the previous conversation. Actually, it
would be nice to add an EDTF export. (adding to TODO).
Re Error detection: yes, that's true. Probably should be there. Adding to
todo.
(I am not so much worried about error detection, but rather about error
reporting...)
We have an own datatype planned for shapes, probably something based on the
GeoJSON. The alternative would be just to point out to the respective
entities in OSM, but OSM has a policy against stuff like historical
country borders or geographic range of the long-eared hedgehog, so it is
a good idea
The problem is is that 20120101 is ambiguous -- it could be either the
year 20120101,
or the 1st of January of last year.
Whereas admittedly it is more likely to be the latter, it might be
considered a bit too much magic to guess 2101 as the first of January
of 2000 and 2000 as in 20 Mio
If you enter 15. Jan 2013 it will know the difference. The goal of the
datatype is to understand a point in time within a given precision. 15th of
January is not a point in time, it is a recurring date, and therefore not
in the domain of this datatype (just as Easter is not, nor Sunday).
Whereas I would agree in the case of a calendar, in case of Wikidata I
would think there are many historical dates.
If someone enters 12, I would assume the year 12 AD and not December
2013 or January 12th, 2013.
Also, since we show the interpretation immediately and the editor has
direct
Should the coordinates 456,-234 be understood as 84, 126, or should they
just be an error?
2013/1/3 Andy Mabbett a...@pigsonthewing.org.uk
On 3 January 2013 16:11, Denny Vrandečić denny.vrande...@wikimedia.de
wrote:
What it currently does not do is:
* enable dates like Date of birth:
Some time specifications that aren't parsing:
2:34:06pm
CDT 10pm
2004-01-01T11:20:10Z
Meng
On Thu, Jan 3, 2013 at 8:11 AM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
Hi all,
continuing from last weeks data values discussion, I would like to invite
comments on the following
I tried the coordinate tool with a cordinate i found on geocaching.com N
48° 22.250 E 010° 53.777 the problem is the parser needs data in the
formate 48° 22.250 N 010° 53.777 E. There should be an autodetection to
accept both inputs.
Sk!d
On Thu, Jan 3, 2013 at 5:11 PM, Denny Vrandečić
