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": [
                    "11",
                    "12"
                ],
                "html": {
                    "*": "Out of range, must be no higher than 11"
                }
            }
        ],
        "*": "See https://www.wikidata.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> 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": [
                    "+2017-03-09T02:00:00Z"
                ],
                "html": {
                    "*": "Malformed input: +2017-03-09T02:00:00Z"
                }
            }
        ],
        "*": "See https://www.wikidata.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> 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.

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.

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

In T57755#4160408, @Lea_Lacroix_WMDE wrote:

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: https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2018/05#Date_and_time_values

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 (https://www.wikidata.org/wiki/Q26961029).

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:

In T57755#4160408, @Lea_Lacroix_WMDE wrote:

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

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

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

4. 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:

• Decision on what a "better" precision is. StructuredDataOnCommons wants second precision?
• Check and possibly implement Parsers and Formatters for values with a better precision. It looks like there are some basic parsers implemented for this https://github.com/DataValues/Time/blob/master/src/ValueParsers/IsoTimestampParser.php#L159-L164 (but noting extra inside wikibase). As for formatters there are currently no tests for anything more precise than a day, so this might not be done https://github.com/DataValues/Time/blob/master/tests/ValueFormatters/TimeFormatterTest.php#L64-L76
• Work on UI elements for this? If this is not immediately being enabled on wikidtaa.org then we don't have to worry about input there, but StructuredDataOnCommons will have to think about that.

The current time data value has its validators limiting to day precision https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/includes/ValidatorBuilders.php#L330-L332
This would either need to:

• change for the default "time" data value, which change both wikidata.org 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?

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 wikidata.org 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 wikidata.org then second precisions will not work.
If other validators are used then commons can have second precision values.

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

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?

In T57755#4661653, @Addshore wrote:

So, this ticket was created specifically for allowing entering time values with second precision on wikidata.org 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 wikidata.org then second precisions will not work.
If other validators are used then commons can have second precision values.

How about just implementing this just for Commons, without timezones and default it to the local time? That is also current practice on Commons, see for example https://commons.wikimedia.org/wiki/File:Northstar_California_Prosser_2.jpg where the time is "3 July 2017, 13:28:12". If someone is really interested in the timezone, they can derive it from the coordinates.

Should we fork the Commons part into another task and keep this one for Wikidata?

! In T57755#6576484, @Multichill wrote:
without timezones and default it to the local time? That is also current practice on Commons, see for example https://commons.wikimedia.org/wiki/File:Northstar_California_Prosser_2.jpg where the time is "3 July 2017, 13:28:12". If someone is really interested in the timezone, they can derive it from the coordinates.

I don't understand how a time could be without a timezone and at the same time have a default timezone.

I also don't understand how local time with hours, minutes, and seconds can be the current practice on Commons and at the same time require a software fix to allow entry of hours, minutes, and seconds on Commons.

Finally, I see a lack of notice and documentation for file contributors. In the file upload dialog in Commons, the following instructions are provided to the uploader:

Date work was created or first published
Choose the date this work was created or first published.

There is no indication about what time zone will be assumed for the creation or first publication date. You can't expect users to provide correct dates and times if you don't tell them at the time of upload that whatever they enter will be assumed to have the time zone that was in force at the time and place where the photo was taken.

In T57755#6576583, @Jc3s5h wrote:

....

There is no indication about what time zone will be assumed for the creation or first publication date. You can't expect users to provide correct dates and times if you don't tell them at the time of upload that whatever they enter will be assumed to have the time zone that was in force at the time and place where the photo was taken.

That's how basic human interaction works? If I say that we'll meet next Saturday at 13:00, the other person knows it's in local time (just switched from CEST to CET). Works the same way on Commons. We don't ask users for time zones and we don't record that data.

Forked the Commons part in T266407 and left this one for the Wikidata part.

In T57755#6576583, @Jc3s5h wrote:

I don't understand how a time could be without a timezone and at the same time have a default timezone.

UTC can be used for this.

I also don't understand how local time with hours, minutes, and seconds can be the current practice on Commons and at the same time require a software fix to allow entry of hours, minutes, and seconds on Commons.

AFAIK, it should be server time. We can just set it to its timezone.

In T57755#6576706, @Sannita wrote:

In T57755#6576583, @Jc3s5h wrote:

I don't understand how a time could be without a timezone and at the same time have a default timezone.

UTC can be used for this.

Situation 1: time can be accompanied by a time zone, which could be UTC. In this case, the time zone is specified.

Situation 2: the time zone of a time in a computer is not recorded. In this situation, the time must be judged from context.

Situation 1 and situation 2 are mutually exclusive.

In T57755#6576646, @Multichill wrote:

In T57755#6576583, @Jc3s5h wrote:

....

There is no indication about what time zone will be assumed for the creation or first publication date. You can't expect users to provide correct dates and times if you don't tell them at the time of upload that whatever they enter will be assumed to have the time zone that was in force at the time and place where the photo was taken.

That's how basic human interaction works? If I say that we'll meet next Saturday at 13:00, the other person knows it's in local time (just switched from CEST to CET). Works the same way on Commons. We don't ask users for time zones and we don't record that data.

This is not basic in-person interaction. This is interaction among people all over the globe by means of computers.

Well, how one could write a timezone for {{Q|Q3062714}}, whose guillotine worked on 10 h 22, Paris Time (given the fact that in 21 JAN 1793, UTC didn't exist) ?

In T57755#6593446, @Bouzinac wrote:

Well, how one could write a timezone for {{Q|Q3062714}}, whose guillotine worked on 10 h 22, Paris Time (given the fact that in 21 JAN 1793, UTC didn't exist) ?

At present, we can't give the date and time when Louis XVI was executed. As you can see from the discussion over the last 3 years, several substantially different approaches have been suggested and no choice among them has been made yet.

I don't know what time of day Louis XVI was executed, but I'll suppose for the sake of discussion 10 h 22 m Paris time is correct. The first step is to determine if this is apparent solar time or mean solar time. If it is apparent solar time, and the time scale selected is a mean time scale, we would have to convert it. I don't have a converter handy that would work for that date.

UTC didn't exist before about 1962. The time scale that has noon at Greenwich occurring at 12 h 0 m, and can be projected back for many centuries, is UT1. The longitude of Paris is 2.3522 degrees East. Each hour of mean time is equivalent to 15 degrees of longitude, so 2.3522 degrees corresponds to 9 minutes. So mean Paris time is 9 minutes ahead of UT1.

I see the following use cases:

• A source states that the death of .. occurred at 9:25 on some day. I would like to save that information and I find the current approach of using refine date (P4241) = 09:25 (Q55810989) qualifier totally crazy
• In case of images on Commons, like this one, upload wizard saved the date "9 March 2019, 17:20:46" and I would like to store it in SDC. I need up to a second precision if I want to order write SPARQL query of photographs from that event and sort them in a chronological order. In such a case the timezone is irrelevant.

Just to add another dimension to the use cases. In addition to domain-specific reasons for accurate dates, there are some provenance modelling reasons too. For example, adding a statement reference (or qualifier) that describes when a statement was observed or known to be true. For this it would be desirable to have full ISO8601 (i.e seconds, but why not milliseconds?)

I added short summary about the current situation at Help:Dates#Hours,_minutes_and_seconds.

I am playing around with an wikibase for events, it would be really good to be able to just use "start time" instead of relying on qualifiers. Any progress on that direction, at least for wikibase / wbstack? (@Addshore ?)

I (accidentally) created higher precision values. However, after that the items can not be edited anymore.

Change 992681 had a related patch set uploaded (by Physikerwelt; author: Physikerwelt):

[mediawiki/extensions/MathSearch@master] Reduce precision of timestamps to days

https://gerrit.wikimedia.org/r/992681

Change 992681 merged by jenkins-bot:

[mediawiki/extensions/MathSearch@master] Reduce precision of timestamps to days

https://gerrit.wikimedia.org/r/992681

Change 1010986 had a related patch set uploaded (by Physikerwelt; author: Physikerwelt):

[mediawiki/extensions/MathSearch@master] Remove time information from TimeValue

https://gerrit.wikimedia.org/r/1010986

Change 1010986 merged by jenkins-bot:

[mediawiki/extensions/MathSearch@master] Remove time information from TimeValue

https://gerrit.wikimedia.org/r/1010986