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), multiplied by 4 to convert to minutes. > > > I think representing two semantics in one value is not a good idea. One data > value should have only one semantics - either this is always minutes, or this > is a longitude, but not both. Otherwise, handling such fields becomes very > complex, and more complex code breeds errors and inconsistencies. If we allow only the existing format and also allow only time zones, time zone offsets will be disallowed before 1880, which is when the first time zones were established in the British Isles. This would prevent accurately representing statements about events before the establishment of time zones if the date is know with certainty according to local time, but there is not enough information to state what the date would be in Universal Time. > > The "precision" field identifies which characters in the "time" field must > > be valid date or time representations > > > I would rather keep all characters valid, even for year-only dates. The > reason is that otherwise it is very hard to compare "year 1200" to "12 April > 1976" - since the former can not be converted to any point in time. > Admittedly, "year 1200" describes not one point in time but a set of them, > but for most applications (like "give me all painters born in 13th century in > Europe") it is good enough. Not being able to use standard time handling > tools to process such data is worse. The existing entries contain a great many examples of invalid characters such as "00" for the month or date. So requiring that all digits be valid would require having a bot run through the whole database and fixing all the invalid entries. > > > > The "time" value may be truncated at any point right of the rightmost day > > digit > > > The more options the format has, harder it is to parse it correctly and more > opportunities there is for bugs in various code and tools. I'd rather keep it > simple and have full time always. The converse risk is that some tool will only look at the time value rather than all the fields, and falsely conclude the date and time of Abraham Lincoln's birth is +1809-02-12T05:42:57 plus or minus one second. TASK DETAIL https://phabricator.wikimedia.org/T99674 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jc3s5h Cc: JanZerebecki, Smalyshev, Jc3s5h, daniel, Aklapper, Tobi_WMDE_SW, Wikidata-bugs, JulesWinnfield-hu, Addshore, Liuxinyu970226, Rical, Conny, aude _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
