Import from Jira Cloud buggy / has issues with alleged custom fields

Created May 27, 2026 12:19

Hi,

I have two issues with the import from jira cloud.

Import config rarely reaches page 3 / only after a long time

the import from jira cloud rarely gets to page 3 where I specify the config. Weirdly enough, the confluence import from the same instance works.

I've tried various base URLs, first the one listed in the docs: https://www.jetbrains.com/help/youtrack/cloud/new-import-from-jira.html#setup-procedure

https://instancename.atlassian.net/

Then also:

https://instancename.atlassian.net/jira (because for confluence /wiki is added)

Then also

https://instancename.atlassian.net

(just in case no trailing / is needed)

… but nothing. I've also used another API token than the one generated for jira.

I'm willing to put this down to lol atlassian makes api calls slow. A note in the docs that it might take some time would be really reassuring.

Import fails due to mandatory field of “completion date” when jira suspects german locale

However, at some point it worked with https://instancename.atlassian.net/. So far, so good. However, it crashed pretty early on:

Importstatus
[442-12] The specified timestamp 10/Mär/21 8:20 PM doesn't match any of the predefined patterns: yyyy-MM-dd HH:mm, dd.MM.yyyy HH.mm, dd.MM.yy HH:mm, dd.MM.yy, yyyy-MM-dd'T'HH:mm:ss.SSSX, yyyy-MM-dd'T'HH:mm:ssX, yyyy-MM-dd'T'HH:mmX, yyyy-MM-dd, dd/MMM/yy HH:mm, dd/MMM/yy

This happens whether i import with history or not. In the logs, the issue becomes clearer:

Script failed with error: The data type for the {Project with id=10000 key=ALLY}.{Issue with key ALLY-413 and id 10216}.{history[0] with id 11505-0}.fieldChanges.customfield_10009.addedValues[0].value field is declared as datetime, but its value is stored as 10/Mär/21 8:20 PM.

→ The value is the german localized version for 10th of March 2021. My jira instance however is in english. I've also adjusted (just to be sure) the look and field of dates to be in yyyy-mm-dd format, but no luck.

The mentioned field is the completion date, which is created by jira, so I have no influence on how the values are stored / handled.

Any tips on how I need to configure the import script and how to then run it? I'm (not yet) a Java Dev.

Log files:

Upload id: 2026_05_27_R1zaekvChQVzAQquTaeD2k (files: import_442-9.log and 2 more)

4 comments

Sergey Merzlov

Created May 27, 2026 16:26

Official comment

Hi,

I'm Sergey from the YouTrack Team. Thanks for reaching out!

I checked the import logs. The crash happens when YouTrack processes the Jira Completion Date custom field history for issue ALLY-413. Jira returns this history value as a localized display string:

10/Mär/21 8:20 PM

The default import script doesn't parse this German month abbreviation combined with the AM/PM time format, so the import stops with the timestamp error.

Please try customizing the Jira import script:

Open Administration > Integrations > Imports.
Open your Jira import configuration.
Click the edit pencil and select Customize the import script.
In the utils file, replace sourceMonths with German month abbreviations:

const sourceMonths = [
  'Jan', 'Feb', 'Mär', 'Apr', 'Mai', 'Jun',
  'Jul', 'Aug', 'Sep', 'Okt', 'Nov', 'Dez'
];

In the client file, find getTimestampFormats() and add dd/MMM/yy h:mm a before dd/MMM/yy HH:mm.

You can find the general Jira import setup documentation here: Import from Jira.

For the slow setup step, the logs you shared don't show a slow Jira API response during project retrieval, so I don't have enough details to diagnose that part yet. If it happens again, please the detailed description of the issue with examples. We'll help you investigate it further.

JetBrains User 26644557502866

Created May 28, 2026 08:56

thank you so much! It works, however, for some reason unknown to me, it now has FRENCH timestamps, too – at least "janv." indicates so far. I suspect that Jira just flat out saves the timestamp in a string of whatever locale is currently used at the time of change (I do not know what would compel them to implement it that way). I'll try to fiddle around and if I figure it out, I'll let you know!

28/05/26 08:34:25,236 ERROR [335-12] [mportLogging] Script failed with error: The data type for the {Project with id=10000 key=ALLY}.{Issue with key ALLY-1326 and id 11122}.{history[2] with id 19471-0}.fieldChanges.customfield_10009.addedValues[0].value field is declared as datetime, but its value is stored as 12/janv./25 8:50 AM.
jetbrains.youtrack.imports.api.IncorrectDataFormatException: The data type for the {Project with id=10000 key=ALLY}.{Issue with key ALLY-1326 and id 11122}.{history[2] with id 19471-0}.fieldChanges.customfield_10009.addedValues[0].value field is declared as datetime, but its value is stored as 12/janv./25 8:50 AM.

JetBrains User 26644557502866

Created May 28, 2026 09:15

Update: the solution was that I had to (when it failed for the last time) edit the source months again to the German-French-mélange of:

const sourceMonths = [
  'janv.',
  'fev.',
  'Mär',
  'Apr',
  'Mai',
  'Jun',
  'Jul',
  'Aug',
  'Sep',
  'Okt',
  'Nov',
  'Dez'
];

And then resume the same import. So essentially only changing what the import has an issue with and try how far it gets with the changed settings.

Sergey Merzlov

Created May 28, 2026 14:20

Hi,

Thank you for the update!

Yes, your conclusion looks correct. Jira appears to have stored values for this field using different locale-specific display strings over time. This isn't a common case, so we don't have a pre-built import script configuration that accounts for all possible mixed-locale values, but the workaround is applicable here.

The import script can only parse the month names and timestamp formats that are explicitly listed in the script. If the Jira data contains a mix of German, French, or other localized month names, the script needs to be adjusted for the variants that appear in the data.

In this case, your updated sourceMonths mapping looks like the right approach:

const sourceMonths = [
  'janv.',
  'fev.',
  'Mär',
  'Apr',
  'Mai',
  'Jun',
  'Jul',
  'Aug',
  'Sep',
  'Okt',
  'Nov',
  'Dez'
];

Then resume the same import. If it fails again with another localized month value, update sourceMonths to match the new value from the error message and resume the import again.

Please keep dd/MMM/yy h:mm a in getTimestampFormats() as well, since the failing values use the AM/PM time format, for example 12/janv./25 8:50 AM.

Let me know if the import runs into another timestamp format after this!

Please sign in to leave a comment.