The csv bulk import doesn't seem to import Original Estimate correctly

Stephen Slade May 29, 2015

If I create a text file saved as .csv with the following content:

Summary, Original Estimate

this test, 3600

 

When I bulk import this, 3600 should set the Original Estimate field to 1 hour, but instead it sets the field to 1 minute.

10 answers

4 votes
Alexey Lizurchik June 30, 2018

The problem still is at least for jira cloud. For me works variant with converting estimate to seconds and them multiply it by 60 (it's weird, but it works), e.g.:

You want estimate task as 6 hours. Convert 6 hours to seconds at first: 6 * 60 * 60 = 21600. And them multiple by 60 once again just in order to be parsed by jira import correctly.

With days it's more tricky. You have to keep in mind that for jira 1 day equals 8 hours (or whatever you set in project settings). So, to estimate task e.g. as 2 days, at first convert days to hours (consider 8 hours as a day): 2 * 8 = 16 hours. Then convert it to seconds: 16 * 60 * 60 = 57600. And finally, multiply it by 60: 57600 * 60 = 3456000. So the resulting value which you should put in your csv is 3456000 which means 2 jira's days.

Multiplying seconds by 60 is a bug. Don't consider it as a rule. It's just a workaround for now. JIRA must fix it

marco_schottke July 4, 2018

Thanks ;-) You save my day !!!

Ilya Feldshteyn January 15, 2019

Thank you! 

Mitali Bhade May 15, 2019

Thank you,it worked .

Keith Pope May 21, 2019

Is there a bug entered for this?

Greg.Richards September 2, 2019

This workaround doesn't seem to be working anymore....

 

Example of data I have tried to upload:

 

1 day = 8 hours -> 8

8 hours = 8*60*60 seconds = 28800 seconds -> 28800

28800 seconds = 1728000 millseconds -> 1728000

 

Every other piece of info is being created with the issue, just not the estimate. Totally frustrating!!

2 votes
Stephen Slade May 29, 2015

Summary, Original Estimate, Remaining Estimate, assigned
this test, 3600000, 0, admin

 

That imports as 2d 40m.

The help section says that Original Estimate imports as seconds.

1 vote
Alex Marschner January 31, 2019

I just ran through this one with Atlassian support on JIRA v7.12.1

There does appear to be a bug when the default time tracking unit is 'minute'.  When I changed that value (Administration > Issues > Time Tracking) to 'hour' the import happens correctly (ie an 'Original Estimate' entered in seconds is correctly divided into the expected week/day/hour value).

Ilya Feldshteyn January 31, 2019

You are absolutely right, I figured this out myself but neglected to leave a follow-up (shame on me!). Confirm that solution works! 

Ilya Turov
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 20, 2019

hope more people will see this answer, not the "workaround"

but that's definitely some weird logic

Gil Vinokoor April 22, 2020

So @Alex Marschner (or @Ilya Feldshteyn @Ilya Turov) just to be 100% clear, if:

1. The default unit for time tracking is set to "hour" in Jira, and 

2. The Original Estimate value - for example, 1 hour - is entered in seconds, i.e. 3600 in the CSV file, then

3. After the CSV import, Jira will show in the Original Estimate field?

Like joel.murav likes this
Gil Vinokoor April 22, 2020

My experience just now - I followed the steps I noted above (using Jira v7.13.12 with default time tracking set to "hour") with Original Estimate = 432,000 (i.e. 5 days), I got the following error message on the Validation of Map values:

Unable to parse original estimate: [432,000]

What am I doing wrong...or is Jira doing wrong? :(

Susan Wilson April 22, 2020

Do you have the comma in the value?  If so, try 432000 instead and see if that works.

Like Gil Vinokoor likes this
Gil Vinokoor April 22, 2020

That did the trick, @Susan Wilson! :)

Removing the comma is what I did and it worked like Alex mentioned above.

*Now, the folks at Atlassian just need to fix this bug that requires one to enter estimates in seconds - and without commas - even if the default unit for time tracking is hours!*

Like Susan Wilson likes this
1 vote
Kian Pariwar January 10, 2017

i have a similar problem:

it works for me in seconds as long as the amount of seconds is 1 hour or more.

however, it does not work if I try to enter an amount of seconds which is below 1h, instead of showin 0,5h in original estimate field, JIRA shows me 0.

Short note: i changed the default number value for time tracking to hours instead of minutes 

0 votes
Deleted user November 6, 2017

I wanted to CSV-import issues containing Original Estimate with an amount of hours. It didn't import correctly.

I could solve the problem by multiplying the formula h*3600*60=h*216000 and importetd again.

Strange behaviour. Documentation needs updating here.

0 votes
Gyula Tarjani May 8, 2017

Hello everyone,

We are having the very same issue with the CSV import working properly when trying on our evaluation server but not on our production instance. On the evaluation server importing the following CSV results in the original estimate being set to 1 hour (which is according to the documentation correct).

Summary;Issue Id;Component;Assignee;Reporter;Issue Type;Priority;Original Estimate;Start date;Due Date
Set up demo for client;BUSTEST-4;Pre-sales;test;test;Task;Medium;3600;2016.12.10.12:00;2017.01.02.12:00

Importing the very same CSV file on the production server results in the original estimate being set to 1 minute. Anyone experiencing the same issue as us?

 

0 votes
Stephen Slade July 9, 2015

It started working correctly again, so I guess so.

0 votes
Benjamin Sewards July 8, 2015

Has this been resolved?

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 29, 2015

The import thinks in milliseconds, so you're importing a few seconds, which JIRA rounds up to 1 minute.  

Try 3,600,000

Ben Herron February 28, 2018

This goes directly against what the documentation says

Suggest an answer

Log in or Sign up to answer