Page MenuHomePhabricator

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


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).


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



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:24 AM
bzimport set Reference to bz65267.
bzimport added a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).

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.

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.