# What is time stamping error and how to fix it? **URL:** \ **Category:** Technical Support\ **Tags:** metadata\_manager, timestamp, deposits, depositor-report\ **Created:** [23 November 2018 11:02 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932 "2018-11-23T11:02:36Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Anjum](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/anjum/32/53_2.png) [@Anjum](https://community.crossref.org/u/Anjum)\ **Post date:** [23 November 2018 11:02 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/1 "2018-11-23T11:02:36Z")
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 ---
**Author:** ![ifarley](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/ifarley/32/44_2.png) [@ifarley](https://community.crossref.org/u/ifarley)\ **Post date:** [26 November 2018 14:21 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/2 "2018-11-26T14:21:20Z")
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 \ 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](http://www.crossref.org/06members/51depositor.html) When we launched the new [Metadata Manager tool](https://www.crossref.org/metadatamanager/), 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 ---
**Author:** ![Anjum](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/anjum/32/53_2.png) [@Anjum](https://community.crossref.org/u/Anjum)\ **Post date:** [27 November 2018 03:09 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/3 "2018-11-27T03:09:28Z")
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 ---
**Author:** ![ifarley](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/ifarley/32/44_2.png) [@ifarley](https://community.crossref.org/u/ifarley)\ **Post date:** [27 November 2018 16:41 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/4 "2018-11-27T16:41:53Z")
My pleasure, Anjum. We’re excited about Metadata Manager, too! ---
**Author:** ![prachi.ansf](https://avatars.discourse-cdn.com/v4/letter/p/8dc957/32.png) [@prachi.ansf](https://community.crossref.org/u/prachi.ansf)\ **Post date:** [12 October 2020 19:01 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/5 "2020-10-12T19:01:19Z")
I am in a similar situation using the web deposit form. Please review the following message: \ \ \1479748515\ \\_1602524501\ \ Successfully updated in handle \ \ Successfully updated \ \ Record not processed because submitted version: 1602524601 is less or equal to previously submitted version {1} \ \ Successfully updated \ I am not an expert but I used the [https://www.epochconverter.com/](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! ---
**Author:** ![ifarley](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/ifarley/32/44_2.png) [@ifarley](https://community.crossref.org/u/ifarley)\ **Post date:** [12 October 2020 19:26 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/7 "2020-10-12T19:26:58Z")
> [@prachi.ansf](#): > > 1479748515 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](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](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](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](https://data.crossref.org/depositorreport?pubid=J395573) Warm regards, Isaac ---
**Author:** ![prachi.ansf](https://avatars.discourse-cdn.com/v4/letter/p/8dc957/32.png) [@prachi.ansf](https://community.crossref.org/u/prachi.ansf)\ **Post date:** [13 October 2020 03:02 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/8 "2020-10-13T03:02:29Z")
> [@prachi.ansf](#): > > \_1602524501 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? ---
**Author:** ![ifarley](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/ifarley/32/44_2.png) [@ifarley](https://community.crossref.org/u/ifarley)\ **Post date:** [13 October 2020 13:15 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/9 "2020-10-13T13:15:48Z")
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 ---
**Author:** ![farname](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/farname/32/1629_2.png) [@farname](https://community.crossref.org/u/farname)\ **Post date:** [2 July 2024 06:35 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/11 "2024-07-02T06:35:07Z")
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 ---
**Author:** ![ifarley](https://sea2.discourse-cdn.com/flex020/user_avatar/community.crossref.org/ifarley/32/44_2.png) [@ifarley](https://community.crossref.org/u/ifarley)\ **Post date:** [2 July 2024 17:46 UTC](https://community.crossref.org/t/what-is-time-stamping-error-and-how-to-fix-it/932/12 "2024-07-02T17:46:01Z")
Hello @farname , Thanks for your question, and welcome to the Community Forum. The definition of [timestamp](https://data.crossref.org/reports/help/schema_doc/5.3.1/common5_3_1_xsd.html#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