Smalyshev added a comment. > 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. > 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 "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. TASK DETAIL https://phabricator.wikimedia.org/T99674 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev 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
