When I was using web deposit form to deposit the data, I found “time stamping error” in all submissions when I use Web deposit form. However, this error is not there in the Metadata but was happened only after beta testing of Metadata Manager.
Now, I am using Metadata Manager for all deposits without any error.
I am just interested to know about the reason for this error. Some persons may get benefit from this topic who are still using Web deposit.
Anjum
Hi Anjum,
Thanks for your message.
The error message ‘Record not processed because submitted version: ___ is less or equal to previously submitted version (DOI match)’ indicates that the timestamp in your deposit is numerically lower than (or equal to) the timestamp used in a previous deposit.
Every deposit has a <timestamp> value, and that value needs to be incremented each time the DOI is updated. You can find the most recent timestamp by reviewing your past deposit XML, which is created for you when using the web deposit form (and emailed to the email address you enter at the end of the form). Timestamps are also listed in the depositor reports available here: http://www.crossref.org/06members/51depositor.html
When we launched the new Metadata Manager tool, we automated the creation of the timestamp. Metadata Manager uses a 17-digit timestamp using the YYYYMMDDHHMiMiSSmmm format (where Y = year; M = month=; D = day; H = hour; Mi = minute; S = second; and m = millisecond). Our schema does allow for timestamps of 19 digits, so the only way of triggering a timestamp error in Metadata Manager is if a member created XML outside of Metadata Manager with a timestamp greater than (or equal to) the 17-digit timestamp autogenerated, using UTC time, by Metadata Manager and then added that record to Metadata Manager and attempted to update the existing metadata record. That’s a long way of saying very few members should ever see a timestamp error when using Metadata Manager to register or update their records.
Best regards,
Isaac
Dear Issac,
Thank you for the information.
Yes. Metadata is improved and it keeps away many errors which were reported in the Web deposit form.
Anjum
My pleasure, Anjum. We’re excited about Metadata Manager, too!
I am in a similar situation using the web deposit form. Please review the following message:
<?xml version="1.0" encoding="UTF-8"?><doi_batch_diagnostic status=“completed” sp=“ds5”>
<submission_id>1479748515</submission_id>
<batch_id>_1602524501</batch_id>
<record_diagnostic status=“Success”>
Successfully updated in handle
</record_diagnostic>
<record_diagnostic status=“Success”>
Successfully updated
</record_diagnostic>
<record_diagnostic status=“Failure” msg_id=“4”>
Record not processed because submitted version: 1602524601 is less or equal to previously submitted version {1}
</record_diagnostic>
<record_diagnostic status=“Success”>
Successfully updated
</record_diagnostic>
I am not an expert but I used the https://www.epochconverter.com/ to see if 1602524601 is less than 1602524501 and I think it is not.
What am I missing here?
Thank you!
Hi @prachi.ansf. Thanks for your message. We use timestamps to uniquely identify batch files and DOI values when a DOI has been updated one or more times. The timestamp is an integer representation of date and time that serves as a version number for the record that is being deposited.
The last successful update made for DOI 10.47552/ijam.v1i2 used timestamp 1602526105 in submission https://doi.crossref.org/servlet/submissionAdmin?sf=detail&submissionID=1479749052.
In the submission in question - https://doi.crossref.org/servlet/submissionAdmin?sf=detail&submissionID=1479748515 the timestamp used was 1602524601.
It looks like you have corrected this issue with your most recent submission https://doi.crossref.org/servlet/submissionAdmin?sf=detail&submissionID=1479749052.
Our depositor reports also list all of the timestamps used for a journal’s DOIs. Here’s the depositor report for the journal International Journal of Ayurvedic Medicine (ISSN 09765921) : https://data.crossref.org/depositorreport?pubid=J395573
Warm regards,
Isaac
Thank you very much. This is really helpful. I will review the depositor report to crosscheck the timestamps.
One other thing I wanted to double-check was that can we increase the timestamp value by any random number to make it greater than the previously submitted version when we submit the revised version?
Yes, @prachi.ansf, you should increase the value of your timestamp for each submission. Our internal timestamp for the web deposit form and Metadata Manager uses the current date as the timestamp in this format:
YYYYMMDDHHMiMiSSmmm format (where Y = year; M = month=; D = day; H = hour; Mi = minute; S = second; and m = millisecond)
Some of our members adopt similar formats using dates (e.g., YYYYMMDDHHMiMi) for their timestamps.
My best,
Isaac
Dear @ifarley,
I hope that you’re fine.
Thank you for the information.
According to the international standard, a time stamp is a string of numbers calculated in seconds since Jan 01 1970 (UTC).
Based on website unixtimestamp[dot]com , according to the Timestamp standard, it is a string of 10 digits.
For example, for the current date:
Coordinated Universal Time (UTC)
YYYYMMDDHHMiMiSS format: 20240207063033
Convert to Unix Timestamp is 1719889233
Which is correct?
Or is it correct to use both?
Sincerely
Publisher Team
Hello @farname ,
Thanks for your question, and welcome to the Community Forum.
The definition of timestamp in our schema is:
An integer representation of date and time that serves as a version number for the record that is being deposited, used to uniquely identify batch files and DOI values when a DOI has been updated one or more times.
Thus, both timestamps - one based on the Coordinated Universal Time (UTC), YYYYMMDDHHMiMiSS format: 20240207063033 OR one based on the Conversion to Unix Timestamp format: 1719889233 - are perfectly acceptable. For that matter, other timestamps are also fine to use. The critical piece of this is to be consistet with the format being used. We expect that for each subsequent submission of a DOI the timestamp will be incremented, so as long as you are updating 20240207063033 to 20240207063034 and 1719889233 to 1719889234 and 000000003 to 000000004, you can use the format of your choice.
Warm regards,
Isaac