gerritbot added a comment.
Change 200845 merged by jenkins-bot:
Update Special:ListDatatypes for TimeValue
https://gerrit.wikimedia.org/r/200845
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or
gerritbot added a subscriber: gerritbot.
gerritbot added a comment.
Change 200845 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Update Special:ListDatatypes for TimeValue
https://gerrit.wikimedia.org/r/200845
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER
JulesWinnfield-hu added a subscriber: JulesWinnfield-hu.
JulesWinnfield-hu added a comment.
Please fix documentation on https://www.wikidata.org/wiki/Special:ListDatatypes
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER ACTIONS
Reply to comment or attach files, or
thiemowmde added a comment.
https://github.com/DataValues/Time/pull/56 is also part of this.
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
adrianheine added a subscriber: adrianheine.
adrianheine added a comment.
Only https://github.com/wmde/DataValuesJavascript/pull/71 is still open.
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or
Jc3s5h added a comment.
Please see my proposed ISO 8601 profile for Wikidata
https://www.wikidata.org/wiki/User:Jc3s5h/ISO_8601_profile_for_Wikidata. I
believe the points in that user page need to be addressed, even if we decide on
a different result than I propose.
TASK DETAIL
thiemowmde added a comment.
The +0019 example is irrelevant for what we do.
Code that does `string.sub(d, 9, 18)` is just wrong, no matter how you look at
it, and can't be of any relevance for what we do. Think about it. What does it
do if it processes the value `-0042000-01-01T00:00:00Z`.
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T66084#996435, @thiemowmde wrote:
Uh, what? What about fixing the documentation? It's marked as //This
document is a draft, and should not be assumed to represent the ultimate
structure// anyway.
My original question is,
thiemowmde added a comment.
No, the question where a fixed number of digits is required is not answered.
Quote: //calendar year is, unless specified otherwise, represented by four
digits//. Great. We do specify otherwise: Between 1 and 16 digits. Done. This
doesn't mean we can't call it an ISO
thiemowmde added a subscriber: thiemowmde.
thiemowmde added a comment.
We had some legacy code (not necessarily PHP, also JavaScript) that padded the
year to 11 digits. Other code pads the year to 16 digits. Note that such
padding is not part of the ISO standard. Therefor my proposal is to drop
Jc3s5h added a comment.
ISO 8601 says The interchange parties shall agree the additional number of
digits in the time element year. I believe thiemowmde is incorrect in claiming
that this can mean the data exchange partners can agree to a variable number of
digits.
Other parts of the standard
thiemowmde added a comment.
Uh, what? What about fixing the documentation? It's marked as //This document
is a draft, and should not be assumed to represent the ultimate structure//
anyway.
My original question is, unfortunately, not mentioned in your responses: What
makes you think ISO
Addshore added a comment.
I agree with the above.
Either we fix it so all dates presented by Wikibase are actually ISO 8601
compliant or just stop saying that its 8601 compliant!
TASK DETAIL
https://phabricator.wikimedia.org/T66084
REPLY HANDLER ACTIONS
Reply to comment or attach files,
Jc3s5h added a comment.
In reply to thiemowmde, P570 (Date of death; the same argument applies to P569,
Date of birth) |has datatype TimeValue. The description of the datatype is at
https://www.mediawiki.org/wiki/Wikibase/DataModel. The first element the
TimeValue structure is described as
Jc3s5h added a comment.
In light of Addshore's comment of January 26, 2015, 23:12, I would say that a
bot must be created to change every date so the year contains exactly 16
digits, and every date with a different number of digits is invalid.
TASK DETAIL
Jc3s5h added a comment.
ISO 8601:2000 contains the following requirement:
If, by agreement, expanded representations are used, the formats shall be as
specified below. The
interchange parties shall agree the additional number of digits in the time
element year. In the examples below
it has
Addshore added a comment.
So:
- Per
https://github.com/DataValues/Time/blob/master/src/DataValues/TimeValue.php#L34
the year should apparently have 11 digits
- Per
https://github.com/DataValues/Time/blob/master/src/DataValues/TimeValue.php#L95
the year is allowed between 1 and 16 digits
-
17 matches
Mail list logo
