Bug report: Overwriting DOI with a non-DOI number

I observe a strange behaviour that Zotero overwrites a DOI after creating an item.
Steps to reproduce:
1) Import the following article with this DOI with the Zotero Connector: 10.1209/0295-5075/110/10001
2) The correct DOI appears after import.
3) But after some time, the DOI is replaced automatically (no input from me) to: 2020031311332586.

[Further details below if needed.]

Using Zotero 6.0.19-beta.1+26847c672 on Windows 10, all add-ons disabled.

The Debug ID is D830359738.
In this Debug ID process, I have tested the following DOIs:
10.1209/0295-5075/110/10001 -> 2020031311332586
10.1209/0295-5075/110/46002 -> 2020031311343294
10.1209/0295-5075/110/47010 -> 2020031311343107
10.1209/0295-5075/110/40002 -> 2020031311350371
I did not understand what triggers the replacement of the DOI, as it was switched at different times for each item.
I have noticed this behaviour only for the papers in this issue of the journal.

It does not seem to be related to the Zotero Connector, as I was able to trigger the same DOI replacement simply by entering manually the DOI in an empty Journal Article item:
1) Create a new empty Journal Article item
2) Enter the following DOI: 10.1209/0295-5075/110/10001
3) Restart Zotero
5) At the end of the sync, the DOI is replaced by: 2020031311332586
But somehow, these steps were less reproducible.

If I re-enter the correct DOIs after restart and sync, they seem to remain stable. So the DOI replacement seems to be related to newly added items.

This seems to be a very narrow bug report, but I am quite surprised why Zotero would change perfectly valid DOIs.
  • (2)(+0000001): Server returned 412: Library has been modified since specified version (expected 79252, found 79253)
    Do you have another synced Zotero with plugins enabled?

    You have two clients syncing, and the item appears to have been modified remotely immediately after it was uploaded by this computer.
  • (As for what the numbers are…hard to say. Could just be sequential, but they're plausibly dates: 20200313113325862020-03-13 11:33:25.86. I don't think they're from us.)
  • Thanks for looking into this.
    The problem indeed goes away when I disable the DOI Manager plugin on the other computer. I will report it on the GitHub of the plugin.
  • As for what the numbers are…hard to say. Could just be sequential, but they're plausibly dates
    Yeah, this would appear to be the timestamp when the DOI metadata was deposited with CrossRef
    -- date-time "2020-03-13T12:22:22Z"
    though for some reason not precisely. Given how limited this is, I almost wonder if this is a CrossRef bug, but @bwiernik (author of the DOI manager) would be able to confirm that more quickly
Sign In or Register to comment.