Page MenuHomePhabricator

Allow time values more precise than day
Open, LowPublic

Assigned To
Authored By
Oct 15 2013, 8:33 PM
"Mountain of Wealth" token, awarded by Sabas88."Like" token, awarded by Sannita."Like" token, awarded by Liuxinyu970226."Pterodactyl" token, awarded by Esc3300."Like" token, awarded by ChristianKl."Like" token, awarded by Saehrimnir."Like" token, awarded by MGChecker.


It is currently not possible to enter time values more precise than 1 day on
We should change this.



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:37 AM
bzimport set Reference to bz55755.
bzimport added a subscriber: Unknown Object (MLST).

API allows this already, only GUI needs support for this

  • Bug 67975 has been marked as a duplicate of this bug. ***
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).

Has the method of adding time zones been determined yet? Claims with the time datatype have a "timezone" property in the data, and it seems to be a simple number. Would this translate, for example, UTC -9:30 to -9.5?

(It would probably be helpful to allow a wide range of options for abbreviations for time zones, by the way.)

MGChecker added a subscriber: MGChecker.
Jonas updated the task description. (Show Details)Aug 13 2015, 9:10 PM
Jonas set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2015, 9:10 PM
Laddo added a subscriber: Laddo.Feb 10 2016, 6:41 PM

I tried a few weeks ago to set a time value more precise than day than day using the API. This also did not work. So I don't agree with duplicatebug that this is only a GUI problem. I think the API problem should be of higher priority.

Jc3s5h added a subscriber: Jc3s5h.Feb 14 2016, 5:27 PM
Saehrimnir added a subscriber: Saehrimnir.
sladen added a subscriber: sladen.EditedDec 3 2016, 12:17 AM

I saw the following diff on my Watchlist:

So I thought I would correct it from "+2016-11-18T00:00:00Z" to "+2016-11-17T23:41Z ±00:01"

The GUI is happy (first attempt only, then it gets confused), and states:

"will be displayed as: +2016-11-17T23:41:00Z"

However, the submission then fails:

"Could not save due to an error. Malformed input: +2016-11-17T23:41:00Z"

and in the JSON:


What is it failing on. Is it the leading '+' (if so, where is that coming from?), or is it still the precision greater than 1 day. If so, this would appear (from the JSON exchange above) to be the API rejecting it, not the GUI.

Jklamo added a subscriber: Jklamo.Feb 24 2017, 4:21 PM

I tried this today via API, and it seems indeed that the limitation is in the API now. If I use the API to push a date with precision 12 (to the hour), I get:

"error": {
        "code": "modification-failed",
        "info": "Out of range, must be no higher than 11",
        "messages": [
                "name": "wikibase-validator-too-high",
                "parameters": [
                "html": {
                    "*": "Out of range, must be no higher than 11"
        "*": "See for API usage. Subscribe to the mediawiki-api-announce mailing list at <> for notice of API deprecations and breaking changes."

If I try with any number other than 0 in the hour slot, I get:

"error": {
        "code": "modification-failed",
        "info": "Malformed input: +2017-03-09T02:00:00Z",
        "messages": [
                "name": "wikibase-validator-malformed-value",
                "parameters": [
                "html": {
                    "*": "Malformed input: +2017-03-09T02:00:00Z"
        "*": "See for API usage. Subscribe to the mediawiki-api-announce mailing list at <> for notice of API deprecations and breaking changes."

So, @sladen , it's from both the precision greater than 11, and from the hour part of the timestamp being different than 00:00:00.

The + at the year is supposed to be there and is valid.

robbi5 added a subscriber: robbi5.Jul 14 2017, 10:57 PM

Hello all,

This issue has been described in this discussion. The goal seems to add, in the date values, the possibility to have the exact time.

In order to investigate on the feasibility of this, I'd like to have a better understanding of what you want, what behaviour should the feature have. Can you help me by answering a few questions?

  1. What would be the input format of the field? How would you like to be able to enter data (format, interface)
  2. How do you expect the data to be displayed once it's validated?
  3. What degree of precision do you require?
  4. How would you prefer to deal with time zones?

Thanks a lot!

According to mw:Wikibase/DataModel#Dates and times, there are already most requirements for timezone support contained in the data model. What prevents us from just activating it? Sure, there will be some GUI changes necessary to enable HH:MM:SS modifications, and to show a timezone selector, but it does not appear too complex to find something there. The highest precision should be seconds (precision=14) to my opinion, as already defined in the data model.

An alternative approach with more required changes could be to save the timezone as URIs instead of “diff minutes to UTC”, akin to the calendarmodel approach. I am not sure whether that would really have advantages, though; maybe display would be easier, since times could be witten as “26 April 2018, 13:43:51 (MESZ / UTC+2)”, rather than “26 April 2018, 13:43:51 (UTC+2)”.

All existing dates have been entered without the ability to specify time zones. Sources for dates would typically include encyclopedias, biographic dictionaries (like ''American National Biography''), newspaper obituaries, etc. For such sources, the time zone is the time zone where the event took place, but this was '''falsely''' entered into Wikidata as UTC. The sources generally do not give the time of day of the event, so it is impossible to convert the date in local time to UTC.

I see two possible approaches.

  1. Rewrite the data model to limit precision to day or looser, and define all dates to be in unspecified local time. Rewrite all the output routines to omit timezone and not put a Z at the end of ISO-8601-like strings. Create a new data type that fully supports time zones.
  1. Create a new data type that supports local time (time zone unspeified). Rewrite all date-holding fields to accept either the existing data type, or the new local time data type. When implementing the change, lock the database and run a bot to change all existing data types to the new local time data type. All old data will be deemed to have an unspecified time zone; only data added after the change will have the possibility of having a time zone. A disadvantage of this approach is that existing external tools that accomodated themselves to the bad behavior of WIkidata will continue to add local times and falsely proclaim them to be UTC.

@Jc3s5h, perhaps a combination is possible, doing both 1. and 2. on API level by introducing new parallel input and output formats with the new features and deprecating the old one that can be deleted later?
It should indeed be possible to define the timezone or not, so we need a precision "11.5" additionally for "day with timezone specified"?

@Marsupium , perhaps the routines could be modified to recognize 11 as "day in local time, no time zone specified" and 11.5 as "day with time zone specified". But currently the data model emits precision as an integer, so all the consumers would have to be modified to accept 11.5 as a float. Not only that, if we start emitting 11 as a float, it will break all the existing emitters. If we emit 11 as an integer and 11.5 as a float, that will complicate consuming software because it will have to be flexible and accept either an integer or a float in that position.

This issue has been described in this discussion. The goal seems to add, in the date values, the possibility to have the exact time.

Since the discussion was archived, the correct link for the discussion is:

What about doing the change in the interface (adding a Timezone: field alongside Precision: and Calendar:) and marking all statements with a date with a qualifier "date without timezone" with a bot like for the gregorian dates issue (

Correct me if I'm wrong, but as far I can see the unique "big" logical problem here is that actually we have not a clear idea about a timezone input. Once we have designed that timezone input picker, all the logical problems are gone. Isn't it?

My take on these questions:

  1. What would be the input format of the field? How would you like to be able to enter data (format, interface)

I did several tests: one way would be 2018-08-22, 11:37 (that it's directly translated as ISO format, even though it can't be saved), another would be the ISO format (+2018-08-22T11:37:00Z).

  1. How do you expect the data to be displayed once it's validated?

AFAIK dates are currently displayed according to user preferences, so it'd be nice to have them consistent with this.

  1. What degree of precision do you require?

It would be nice to have it up to seconds (for example: we know that flight AA11 crashed into WTC1 at 08:46:40 AM UTC-5).

  1. How would you prefer to deal with time zones?

The best option would be to have them integrated, but not mandatory.

I think this will need:

The current time data value has its validators limiting to day precision
This would either need to:

  • change for the default "time" data value, which change both and commons
  • be configurable per repo
  • use a different data type?

Decision on what a "better" precision is. StructuredDataOnCommons wants second precision?

Currently @Magnus wants second precision :) I can see plenty of useful uses for it though. @Ramsey-WMF, should this be part of v1 other statements, or some other v?

Magnus added a comment.Oct 3 2018, 7:55 PM

Well, if we want to put the creation time of a file into a statement, and we have a (sub-)second-precision EXIF time, it seems silly to round it to a day...

@Abit If Community deems it necessary and Team Wikidata agrees on the basics, it's best to have it available for V1 of generic statements on Commons.

So, this ticket was created specifically for allowing entering time values with second precision on and it should probably (i guess) remain just for that.
Having second precision time values on commons does not mean wikidata has to have them.

As said in T57755#4639411 the underlying value object being used already supports second precisions.
Just wikidata has them turned off.
If commons uses the same validators as we use on then second precisions will not work.
If other validators are used then commons can have second precision values.

Addshore renamed this task from allow time values more precise than day to Allow time values more precise than day.Oct 12 2018, 3:56 PM
Addshore updated the task description. (Show Details)

In this context, I would also appreciate a pointer as to enabling second precision on my own wikibase installation.

Pintoch added a subscriber: Pintoch.Feb 2 2019, 6:36 PM

I have updated the Wikibase data model docs, which incorrectly mentioned precisions of hours, minutes and seconds. I assume that they were there because they were part of an earlier design?