| Esc3300 updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
---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.
Note the timevalue also includes a "Z" that can be understood as referring to UTC (with offset 0)It is much more realistic to acknowledge the reality that the dates in the database are, and always will be, local times. The time data value, in reality, contains no information about the time zone and that must be deduced by hints one may find in other properties (such as "place of birth") or outside the database. This despite the current maximum precision being 11 (day) and the documentation mentioning that more precise elements of the timevalue should be ignored.I therefor suggest the paragraph I quoted be revised to read
I believe this is unrealistic"timezone: Signed integer. Unused, and should always be 0 and should always be ignored. If timezones are ever supportedThis parameter turned out to be impractical, 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,and the time data value contains no information about the time zone. 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 zonesThe time data value should be regarded as a local time. It will also be highly problematic to assign a proper time zone to dates that are imported by robots from outside databases.n the future a new data value might be implemented for situations where date and time of day with a precision better than 1 day is desired."
It is much more realistic to acknowledge the reality that the dates in the database are, and always will be, local times. The time data value, in reality, contains no information about the time zone and that must be deduced by hints one may find in other properties (such as "place of birth") or outside the database. I therefor suggest the paragraph I quoted be revised to read
"timezone: Signed integer. Unused believe the present situation may dissuade editors who only wish to add accurate information from participating as Wikidata editors, and should always be 0 and should always be ignored. This parameter turned out to be impractical, and the time data value contains no information about the time zone.because they are unwilling to add dates as being in the UTC time zone when they know this is not true.
---
(added July 4, T2017): Note the time data value shouldevalue also includes a "Z" that can be regardeunderstood as a local timereferring to UTC (with offset 0). In the future a new data value might be implemented for situations where date and time of day with a precision better than 1 day is desired."
I believe the present situation may dissuade editors who only wish to add accurate information from participating as Wikidata editors, because they are unwilling to add dates as being in the UTC time zone when they know this is not true.This despite the current maximum precision being 11 (day) and the documentation mentioning that more precise elements of the timevalue should be ignored.
...
"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."---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.
Note the timevalue also includes a "Z" that can be understood as referring to UTC (with offset 0)It is much more realistic to acknowledge the reality that the dates in the database are, and always will be, local times. The time data value, in reality, contains no information about the time zone and that must be deduced by hints one may find in other properties (such as "place of birth") or outside the database. This despite the current maximum precision being 11 (day) and the documentation mentioning that more precise elements of the timevalue should be ignored.I therefor suggest the paragraph I quoted be revised to read
I believe this is unrealistic"timezone: Signed integer. Unused, and should always be 0 and should always be ignored. If timezones are ever supportedThis parameter turned out to be impractical, 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,and the time data value contains no information about the time zone. 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 zonesThe time data value should be regarded as a local time. It will also be highly problematic to assign a proper time zone to dates that are imported by robots from outside databases.n the future a new data value might be implemented for situations where date and time of day with a precision better than 1 day is desired."
It is much more realistic to acknowledge the reality that the dates in the database are, and always will be, local times. The time data value, in reality, contains no information about the time zone and that must be deduced by hints one may find in other properties (such as "place of birth") or outside the database. I therefor suggest the paragraph I quoted be revised to read
"timezone: Signed integer. Unused believe the present situation may dissuade editors who only wish to add accurate information from participating as Wikidata editors, and should always be 0 and should always be ignored. This parameter turned out to be impractical, and the time data value contains no information about the time zone.because they are unwilling to add dates as being in the UTC time zone when they know this is not true.
---
(added July 4, T2017): Note the time data value shouldevalue also includes a "Z" that can be regardeunderstood as a local timereferring to UTC (with offset 0). In the future a new data value might be implemented for situations where date and time of day with a precision better than 1 day is desired."
I believe the present situation may dissuade editors who only wish to add accurate information from participating as Wikidata editors, because they are unwilling to add dates as being in the UTC time zone when they know this is not true.This despite the current maximum precision being 11 (day) and the documentation mentioning that more precise elements of the timevalue should be ignored.
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
