Timezone offsets cause a 'VS402625: Date must be increasing with each revision' error

[bm-fez]

Describe the problem

I am current doing large scale migrated from an on premise Jira instance to Azure DevOps Services and have encountered a problem when saving some WI revisions. I see the error VS402625: Date must be increasing with each revision.

Due to security restrictions, I cannot provide actual client logs, but have been able to reproduce the problem on a test instance (see details in repo section for how I did this)

[I][10:48:53] Building area cache...
[I][10:48:53] Building execution plan...
[I][10:48:53] Import started. Importing 1 items with 4 revisions.
[I][10:48:53] Processing 1/4 - wi '706', jira 'TEAM-1, rev 2'.
[I][10:48:53] Processing 2/4 - wi '706', jira 'TEAM-1, rev 3'.
[E][10:48:54] VS402625: Dates must be increasing with each revision.
[E][10:48:54] Work Item 706 failed to save.
[I][10:48:54] Processing 3/4 - wi '706', jira 'TEAM-1, rev 0'.
[I][10:48:54] Processing 4/4 - wi '706', jira 'TEAM-1, rev 1'.
[I][10:48:54] Adding single attachment
[I][10:48:54] ID: 4cb08299-f1e0-425d-980b-5d1826545f78
[I][10:48:54] URL: 'https://dev.azure.com/richardfennell/_apis/wit/attachments/4cb08299-f1e0-425d-980b-5d1826545f78?fileName=red.jpg'
[I][10:48:54]
[I][10:48:55] Updated Existing Work Item: '706'. Had 1 attachments, now has 1
[I][10:48:55]
[I][10:48:55] Import complete. Imported 1 items, 4 revisions (2 errors, 1 warnings) in 00:00:03.

To Reproduce

After some investigation of the exported Jira issue JSON files I have found the problem. It is down to the Time format on the revisions.

For the problem to occurs two conditions should be met

• The time has a time zone offset
• The previous revision is within the time period such that applying the offset to the current revision will mean it occurs before the previous one - hence the error

By editing the exported JSON file I can get the following results

Current Revision Time	Previous Revision Time	Result
2014-03-31T08:06:22	2014-03-31T08:04:00	Saves
2014-03-31T08:06:22+01:00	2014-03-31T08:04:00	Error
2014-03-31T08:06:22+01:00	2014-03-31T07:04:00	Saves

Workaround
Given at the offset does not appear to be required (in my data in the UK) my workaround is to edit all the exported .JSON files and remove the time zone blocks i.e. remove the `+01:00' text in all revision time entries.

Once this was done my import worked without error

Analysis
The strange thing with this issue is that there appears to be no pattern as to whether there is a timezone +01:00 block on any given Jira issue revision time. Whether they are present varies even within a single exported Jira issue.

Also, worth noting, that in my client's exported JSON files that I have manually checked, where an offset is present, the revision time is correct before the application of the offset. So I am not sure why the offset is present.

Looking that the Jira export XML for an issue I can see that all the all the times have offsets, but whether they appear in the JSON depend on the user who did the revision. i.e. for my example

User	Jira XML	Exported JSON
User A	Mon, 31 Mar 2014 09:45:01 +0100	2014-03-31Tt09:46:15+01:00
User B	Mon, 31 Mar 2014 09:54:20 +0100	2014-03-31Tt09:54:20

As the XML looks consistent, I suspect the problem lies in FixRevisionDatein the exporter. Unfortunately I cannot run a debug environment on my clients site at present.

I will try to build a test harness to explore this with 'faked up XML', but I thought it worth raising the issue to see if anyone had any thoughts as to the root cause.

Tool version

• Version of the jira-azuredevops-migrator tool
  • Found on 3.0.288
  • Replicated on 3.0.340

Attachments
I cannot provide any actual sample files from my actual client migration, but have been able to replicate the issue using manual edited .JSON file

• Manually Edited .JSON file to show the issue
• Import log

[YoavLax]

Is there a solution for this?
I'm also experiencing this 😥

[haim-saadia]

@bm-fez
May it be related to the asynchrony import?
Changing Time don't really solved that for me

[YoavLax]

For me it solved the issue only for very specific cases, but most of them still are failing.

[YoavLax]

@Alexander-Hjelm Do you have an idea for the area that's causing this issue? Will be happy to contribute and help solve the issue.

In addition, do you recon why this suddenly started happening? It just started appearing very recently.

[Alexander-Hjelm]

@YoavLax @haim-saadia @bm-fez
No update on why timezone offset causes the speicifed issue.

I can maybe mention that I have sometimes received the same error message in either of the following scenarios:

• When migrating Epic links/Parent links where one of the Jira issues was created via the linking dialogue and not via the standard way of creating issues.
• When changing the parent/epic of an issue from one parent to another.

Sometimes these events could cause the events to be logged by Jira in the wrong order. Even if you inspect the issue History tab in Jira and compare the histories of multiple issues, you will see either of the following behaviors:

• a link was created before one of the incoming/outgoing issues were created
• a link was added on an issue before the old link was deleted
• a link was deleted on an issue when there was no link present

We have solved many of these cases with the FixRevisionDates() method, but it could be that there are still cases that need patching.

Any more information that could be relevant for troubleshooting is much appreciated!

The (rather annoying) workaround for now is to manually edit the .json files and bump the timestamp of the affected revisions by a second or so.

[sidey79]

I hit the same issue. Removed the timestamp with a small script but still have trouble that some revisions seems to have a timestamp that ist Not expected.

Also i think, there ist a problem from the timestamp format. IT differs a little bit and months / days are Sometime missinterpreted.

[wallymathieu]

I have a sample that might be of help to create tests for this issue:

[{
    "Time": "2021-02-05T17:00:04.783+01:00",
    "Index": 95,
    //...
},
{
    "Time": "2021-02-12T16:44:01.673+01:00",
    "Index": 96,
    //...
},
{
    "Time": "2022-10-01T08:45:04.767+02:00",
    "Index": 97,
    //...
},
{
      "Time": "2022-10-01T08:47:53.21+02:00",
      "Index": 98,
      //...
}]

[I][14:16:30] Processing 2877/32070 - wi '26305', jira 'W-137, rev 96'.
[E][14:16:30] VS402625: Dates must be increasing with each revision.
[E][14:16:30] Work Item 26305 failed to save.

[wallymathieu]

The dates are strictly increasing, so it looks like the issue is when we get a mix (of offsets) as previously mentioned.

[wallymathieu]

Seems that there is an answer ...
nkdAgility/azure-devops-migration-tools#2216 (comment)

[sidey79]

I had some luck removing the milliseconds from the Timestrings.

[wallymathieu]

We have done the following as a post processing steps of the exported "WiItem":

        for (var revision in item.Revisions)
        {
            revision.Time = revision.Time.ToUniversalTime();
        }

in order to avoid this issue.