Unable to parse multiple date formats during import.

[Raj Vora]

While importing a number of issues, the import of the created date field is unsuccessful for these date formats:

2018-02-13 12:43:49,545 WARN - Unable to parse created date: 31/Dec/17 
2018-02-13 12:43:49,561 WARN - Unable to parse created date: 31-Dec-17 
2018-02-13 12:43:49,562 WARN - Unable to parse created date: Dec/31/17 
2018-02-13 12:43:49,563 WARN - Unable to parse created date: 31/Dec/17 13:02 
2018-02-13 12:43:49,563 WARN - Unable to parse created date: 2017-Dec-31 
2018-02-13 12:43:49,564 WARN - Unable to parse created date: 12/31/17 
2018-02-13 12:43:49,564 WARN - Unable to parse created date: 31 Dec 2017 
2018-02-13 12:43:49,565 WARN - Unable to parse created date: 2017-12-31 
2018-02-13 12:43:49,565 WARN - Unable to parse created date: 31 December 2017

What format does it need to be in?  Does the time (e.g. 13:02) have to be included or can it be omitted?  If it is omitted, what default time does importer use?

I looked at multiple help forums but could not locate the answer.  However one of them discussed the date/time formats screen.  Ours is pretty much the same (see attached) EXCEPT that I noticed there was no instance of date picker format and date time picker format.  Is this a problem?  If so, how do you fix it? 

I am using JIRA Server Edition v7.5.2

[Nic Brough -Adaptavist-]

You have to provide import dates in the same format consistently.  Pick one single format and make sure all your import data uses it.

[Raj Vora]

Well I did that first when trying to import 3 issues, all using 31/Dec/17 as the format.  It did not work.  What are some troubleshooting tips?

After unsuccessfully trying 31/Dec/17 as the format for three issues, that's when I experimented with multiple date formats as described in the details section.

[Nic Brough -Adaptavist-]

Excellent test.  How are you doing the import and what are you telling it the date format is?

[Raj Vora]

I'll have to touch basis with my JIRA administrator (I don't have privileges to do the import but I'm helping design our CSV import files and working with him to test out the process).  So I can get you the proper responses to your questions:

1.  How are you doing the import?

             Is what you want to know the step-by-step procedures/tools we are using to do the import?

2.  What are you telling it the date format is?

             What specifically are you referring to?  When sitting down with my JIRA admin during our test imports, I don't really recall ever being able to specify the date format, unless I am missing something.  Can you point me to a screen snapshot of what you are referring to.

Thanks!

[Nic Brough -Adaptavist-]

Let's step back.  I can think of nearly 16 ways to import issues before reaching for code, so I think we need to narrow that down to what you are looking at.

In other words, yes, I need to know the step-by-step.  Not actually most of it, but let's say the starting steps - how do you get from "I log in to Jira as an admin and go to the admins section" to the point where you know "if I click yes here, I get either issues imported or a shed-load of import errors"

[Brian C. Winkelmann]

Hello, I'm the admin in question :)  We are using a standalone server install of Jira 7.5.2, buill number 75007, with Java Version 1.8.0_102.

I have been given a text CSV file, and am using the Jira supplied CSV importer found under "External System Import".

For reasons we do not understand, when selecting the file the first response is "The CSV file you uploaded contains non-ASCII characters. Make sure to set the right encoding.", which is a surprise, given the pure ASCII nature of all characters in the file.  We leave the file encoding at UTF-8, and CSV delimiter as ,

On the next screen for the importer, we select the destination project, email suffix for new users, and then we come to the crux: "Date Format".

We have been leaving the default, which is dd/MMM/yy h:mm a.

The file we are importing from does NOT include time stamps, only dates, of the forms posted by the OP for our last pass at this.

Then the next pages are a lot of field mapping selections.  The ones of note in here, I would expect, are: 

CSV Field:      Choice made for mapping:

Created      Issue Field: Date Created

Date Fixed    Issue Field: Date Resolved

Now, I do not speak javascript, so I apologize if there is an obvious gaffe in this next part, however;

Under the "System" menu, "Advanced Settings" Button, we have the following set for our date pickers:

jira.date.picker.java.formatThis part is only for the Java (server side) generated dates. Note that this should correspond to the javascript date picker format (jira.date.picker.javascript.format) setting. -> d/MMM/yy

jira.date.picker.javascript.formatThis part is only for the JavaScript (client side) generated dates. Note that this should correspond to the java date picker format (jira.date.picker.java.format) setting. -> %e/%b/%y

jira.date.time.picker.java.formatThis part is only for the Java (server side) generated datetimes. Note that this should correspond to the javascript datetime picker format (jira.date.time.picker.javascript.format) setting. -> dd/MMM/yy h:mm a

jira.date.time.picker.javascript.formatThis part is only for the JavaScript (client side) generated date times. Note that this should correspond to the java datetime picker format (jira.date.time.picker.java.format) setting. -> %e/%b/%y %I:%M %p

I do not personally know if those should all be the exact same, or if in fact %e is the javascript equivalent for "dd" in a date format, %b is MMM, and %y is yy.

[Nic Brough -Adaptavist-]

Forget the advanced settings, they are about display and entry in the application and have absolutely nothing to do with your import.

You are saying that you accept the default format for the import of dd/MMM/yy h:mm a.  That's great, it's a sane date format, and Jira knows that if a field holds only a date, and no time, it can ignore the empty time.

So, the question now is what is in your file.  Is every date either

dd/MMM/yy h:mm a   (e.g. 29/Feb/17 11:45 am)

or

dd/MMM/yy  (e.g. 3/Jun/15 )

If any date is not in one of those two formats, it's going to fail.

[Raj Vora]

When we initially tried the import we used four digits for the year (31/Dec/2017) - I mistakenly told you previously that I used 31/Dec/17.  Does using 4 digits for the years as opposed to 2 digits matter?

If it does matter (which it seems it does), then do you know why we encountered a parsing error when we THEN tried importing multiple issues with multiple date formats (see my initial thread); specifically the one formatted as 31/Dec/17? 

If even one of the formats is incorrect during a multiple issue import, will the parser spit out a warning? 

[Nic Brough -Adaptavist-]

Yet again, stop trying to use many date formats. 

You must use the same format of date for every date in your file.

[Amir Katz (Outseer)]

Just to expand on Nick's answer - When you import, you're asked to select the date format. All the date and date/time fields in your CSV file must be in this format.

If the format that you selected is, for example, yyyy-MM-dd HH:mm, then all date-picker fields must also specify the time (whatever you choose it to be).

Examples:

Date field:          2/10/2018               --> 2018-10-02 00:00

Date/time field: 3/11/2018 1:25 PM --> 2018-11-03 13:25

[Amir Katz (Outseer)]

Two clarifications:

1. The date format applies to the current import operation for one CSV file. When you fire up another import on another CSV file, you can specify a different format, corresponding to the format in the new CSV file.

2. If you save the configuration from the 1st import, the date format is saved as well. You can still override it during the import.

Amir Katz

[Deleted user]

Should be exactly as 10/JUL/19 10:00 AM.  You can not change such data format in Excel, have to be done in TEXT++, TEXT MATE program etc.
JIRA really should update their backend to accept more flexible date format.