| Esc3300 renamed this task from "Revise documentation for "time" data value in Wikibase/DataModel/JSON" to "Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone)". Esc3300 updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
---
Note the timevalue also includes a "Z" that can be understood as referring to UTC (with offset 0). This despite the current maximum precision being 11 (day) and the documentation mentioning that more precise elements of the timevalue should be ignored.
I believe this is unrealistic. If timezones are ever supported, it will never be possible to find enough editors to scour all the existing dates in the database to figure out what the correct time zone is, nor is it likely editors will ever be persuaded to enter the time zone at the same time they enter new dates after the hoped-for implementation of time zones. It will also be highly problematic to assign a proper time zone to dates that are imported by robots from outside databases.
...
"timezone: Signed integer. Currently unused, and should always be 0. In the future, timezone information will be given as an offset from UTC in minutes. For dates before the modern implementation of UTC in 1972, this is the offset of the time zone from Universal time universal time. 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."---
Note the timevalue also includes a "Z" that can be understood as referring to UTC (with offset 0). This despite the current maximum precision being 11 (day) and the documentation mentioning that more precise elements of the timevalue should be ignored.
I believe this is unrealistic. If timezones are ever supported, it will never be possible to find enough editors to scour all the existing dates in the database to figure out what the correct time zone is, nor is it likely editors will ever be persuaded to enter the time zone at the same time they enter new dates after the hoped-for implementation of time zones. It will also be highly problematic to assign a proper time zone to dates that are imported by robots from outside databases.
...
TASK DETAIL
EMAIL PREFERENCES
To: Esc3300
Cc: Lydia_Pintscher, daniel, thiemowmde, Yair_rand, Liuxinyu970226, Pasleim, Aklapper, Jc3s5h, GoranSMilovanovic, Ivana_Isadora, QZanden, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331, Jay8g
Cc: Lydia_Pintscher, daniel, thiemowmde, Yair_rand, Liuxinyu970226, Pasleim, Aklapper, Jc3s5h, GoranSMilovanovic, Ivana_Isadora, QZanden, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
