I think the problem is that instead of a semantic comparison, Wikibase does
a pure string comparison to check if two timestamps are equal. I changed
the primary sources tool on the weekend because there was a bug in the
serialization according to the TSV format specification (it failed a
roundtrip serialize-parse test), which says the year in a timestamp is 11
digits, 0-padded if necessary (i.e. +00000001947 instead of +1947). This
might have broken the comparison.
The weird thing is that later (probably when storing the value in the
database), Wikibase does the right thing (i.e. parses the year even
including leading 0's). So I guess the comparison is happening before that.
I can fix that by rolling back my change that introduced the 0-padding, but
the consequence is that it will no longer follow the definition at
. Or we change
timestamp to the API. But since 0-padding is semantically valid for
numbers, I'd prefer to have a look in the Wikibase backend. There might be
other situations affected by string comparison issues.
On Wed, Apr 6, 2016 at 1:24 PM Lydia Pintscher <Lydia.Pintscher(a)wikimedia.de>
On Tue, Apr 5, 2016 at 10:29 PM Denny Vrandečić
The primary sources tool can add references to
existing claims. For some
reason, it started re-adding the claim yesterday instead.
Did anything change on the Wikidata-side in the last few days that could
be causing this change in behavior? Or should we look harder on the Primary
Bug is being tracked here:
I am not aware of a recent change that should influence this. If you find
it is something in Wikibase please let me know.
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt
für Körperschaften I Berlin, Steuernummer 27/029/42207.