The document Wikibase/DataModel/JSON says "NOTE: The canonical copy of this document can be found in the Wikibase source code and should be edited there. Changes can be requested by filing a ticket on Phabricator" hence this ticket.
The documentation for the timezone parameter within the "time" datavalue states
"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.
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, 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. The time data value should be regarded as a local time. 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.
(added July 4, 2017): 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.