Page MenuHomePhabricator
Create Task
Maniphest T67267

Specify whether TimeValue stores timestamps in UTC or local time.
Open, MediumPublic
Actions

Description

TimeValue has a time field and a timezone field. AS per [1], the time field is defined to be in ISO 8601 format, (which, per spec, includes a time zone offset). The current code of TimeValue and related classes expects the ISO time string to always end in Z, indicating the time is in UTC. So, the local time actually represented by the TimeValue would be the timestamp plus the minutes in the timezone field. The corresponding conversion has to be done by all parsers and formatters.

It would probably be easier (and more consistent with out handling of quantities) to store the time as an ISO date in the time zone specified by the user, so the timezone field would only be needed to derive the UTC time (which we really need only to build the query index). This would mean much fewer occasions that require conversion, and would thus be less error prone and easier to maintain. It would also be consistent with the idea to "save what the source sais".

If we go that route, we should remove the time zone info from the time field of TimeValue, and rely on the separate timezone field to provide an offset. We could even have a special value there (e.g. false) for indicating an unknown time zone (would be treated like UTC for conversion, but not for display).

[1] https://www.mediawiki.org/wiki/Wikibase/DataModel#Dates_and_times

Version: unspecified
Severity: normal
Whiteboard: u=dev c=backend p=0

Details

Reference
bz65267

Related Objects
Search...

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:24 AM
• bzimport added a project: MediaWiki-extensions-WikibaseRepository.
• bzimport set Reference to bz65267.
• bzimport added a subscriber: Unknown Object (MLST).
daniel created this task.May 13 2014, 5:07 PM
Lydia_Pintscher added a project: Wikidata.Dec 1 2014, 2:42 PM
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Tobi_WMDE_SW added a parent task: T87764: Bugs related to time datatype (tracking).Jan 28 2015, 2:19 PM
Jc3s5h subscribed.Jun 16 2015, 3:36 PM
Lydia_Pintscher moved this task from incoming to needs discussion or investigation on the Wikidata board.Apr 23 2017, 4:02 PM
Esc3300 mentioned this in T146499: Revise documentation for "time" data value in Wikibase/DataModel/JSON (timezone).Jul 4 2017, 10:44 AM
Jc3s5h added a comment.Jul 24 2017, 2:21 PM

While being clear about the specification, we should specify that for both the Julian and Gregorian calendars, we consider the year to begin on, and the year number to be incremented on, January 1. Historically some countries have had other conventions.

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptJul 24 2017, 2:21 PM
daniel closed this task as Resolved.May 30 2018, 12:28 PM
daniel claimed this task.

This has been resolved a long time ago. The spec reads:

timestamp in a format resembling ISO 8601, the year always being signed and having between 1 and 16 digits, e.g. +2013-01-01T00:00:00Z. The month, day and time will be set to zero if they are unknown; the precision field should be relied on to determine which time digits are meaningful. The Z is meaningless and the time zone should be determined from the timezone field.

Having a meaningless time zone suffix in the date string is annoying, but the spec is quite clear in saying that the time is indeed local time, always. So this task as described is done.

Jc3s5h reopened this task as Open.EditedMay 30 2018, 1:21 PM

daniel's statement at 08:28 May 30 2018 is not correct. The spec daniel quotes states "...the time zone should be determined from the timezone field." The time zone field is always set to 0. Therefore the time zone is always UT. Daniel's statement "the spec is quite clear in saying that the time is indeed local time, always" is a direct contradiction of the spec.

The only way I can imagine a person might write "the spec is quite clear in saying that the time is indeed local time, always" is if the person was thinking of the local time of the Wikidata servers, and the Wikidata servers are set to UTC. But such an interpretation of "local time" is invalid. "Local time" means the local time of the place where the event associated with a Wikidata date occurred. For example, the local time associated with the birth of George Washington is that of Westmoreland County, Virginia, 78.6 degrees west longitude. That would be -307 minutes in the data model, if and when non-zero values are supported.

Clearly the data model says that when timestamp and timezone fields of the TimeValue type are taken together, it is supposed to represent a local time. It is equally clear that the ability to enter real time zones has been unsupported for many years, and it has been so long since any progress has been made, a reasonable person will presume it will never be supported. It is equally clear that most dates in Wikidata are in reality given in the local time where the event occurred, not UTC, despite what the spec says.

daniel removed daniel as the assignee of this task.Oct 27 2020, 3:55 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL