Pintoch added a comment.
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?TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricat
Sannita added a comment.
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.wikidat
Sabas88 added a comment.
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)
valerio.bozzolan added a comment.
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. Designed that timezone input picker, all the problems are gone. Isn't it?TASK DETAILhttps://phabricator.wikimedia.o
Sannita added a comment.
My take on these questions:
In T57755#4160408, @Lea_Lacroix_WMDE wrote:
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
Addshore added a comment.
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 http
Magnus added a comment.
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...TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/em
Ramsey-WMF added a comment.
@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.TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emai
Addshore added a comment.
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 T5775
Magnus added a comment.
In this context, I would also appreciate a pointer as to enabling second precision on my own wikibase installation.TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MagnusCc: Abit, Magnus
Lea_Lacroix_WMDE added a comment.
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 beha
MisterSynergy added a comment.
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
Jc3s5h added a comment.
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 zon
Marsupium added a comment.
@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 w
Jc3s5h added a comment.
@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
Jobu0101 added a subscriber: Jobu0101.
Jobu0101 added a comment.
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
prio
Yair_rand added a subscriber: Yair_rand.
Yair_rand added a comment.
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
sladen added a comment.
I saw the following diff on my Watchlist:
https://www.wikidata.org/w/index.php?title=Q21980653&curid=24012630&diff=413314375&oldid=413187600
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, t
Andrei_Stroe added a comment.
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",
19 matches
Mail list logo
