Hi,

this is an important issue; is there any comment about a resolution date?

Rose

Hello All,

every friday we need to report the WorkLog export; Kindly raise the priority of this Ticket.

A print/write statement that needs to be extended with a semicolon and a timestamp from an object it is already outputing from. Surely there must be someone working at Atlassian that knows a low hanging fruit when they see one?

Can someone increase the priority of this bug?? all my reports are incorrect because of this bug!!

https://community.atlassian.com/t5/Jira-Software-questions/Work-Log-date-not-matching-the-Export-Issues-file-output-of/qaq-p/1869506

I am running into the same issue...

Export Not Populating 11/4/21 where we want the time spent to be recorded.

• EXPECT: Jira Web Work Log "Logged" Date to match CSV Log Work field
• RESULTS:  Not Matching 
  • JIRA UI ("Date Started")    = 11/4/2021
  • JIRA Issue Excel CSV        = 11/22/21

NOTE: This is a "Subtasks" issue type. I am using subtask to log our time. This Subtasks does roll up to an Issue type = User Story AKY-310.

https://community.atlassian.com/t5/Jira-Software-questions/Work-Log-date-not-matching-the-Export-Issues-file-output-of/qaq-p/1869506

Please dear god in the name of all that is holy, please fix this. Why would anyone want the date the entry was made instead of the date that the entry is specified for?

I agree with Jacek, this is really important

Please fix this bug - this makes worklog reports useless.  We are using customer's Jira and API does not really work for us.

apparently the only way to get something useful from Jira is to use macros and restAPI, json output would be like this:

"worklogs":[
{
"self":"https://jira.com/rest/api/2/issue/xxx/worklog/xxx",
"author":{},
"updateAuthor":{},
"comment":"",
"created":"2020-09-18T12:11:49.000+0300",
"updated":"2020-09-18T12:11:49.000+0300",
"started":"2020-09-14T12:11:00.000+0300",
"timeSpent":"2h",
"timeSpentSeconds":7200,
"id":"xxx",
"issueId":"xxx"

In my case it´s exactly the other way round: 

• Tempo report shows "work date" which is the day when the logged amount occurred (actually needed for management reports
• but issue search only allows searching for "worklogDate()" which is the date when the log has been entered
  • an example that works but delivers the unwanted result: 
    • worklogDate >= "2020/04/01" AND worklogDate <= "2020/06/30"
  • an example that should be possible too but isn´t to my knowledge with "workDate()" not existing as a Tempo custom field that can be searched for:
    • workDate >= "2020/04/01" AND workDate <= "2020/06/30"

Appreciate any hints - in transformations, there will always be a situation where you have to create lump sums in form of time spent. When these efforts actually occurred is the interesting information, not when the log was created. Thank you very much + kind regards!

The experienced a similar issue, but for re-importing the data back into the system.

The workaround I found was:

1. enable export JSON through Manage apps
2. export the issue(s)
3. Use regex/scripting language to clean up the export to match a proper import
   1. No idea why exporting isn't in the format to import....
   2. It is crazy how different the export "worklogs" is from the import "worklogs"
4. Import the issue back into the system via JSON.
5. Disable export JSON.

I also noticed that the "time tracking" bar drastically differed, but the worklogs were identical. This could be a different bug, but I verified in tempo timesheets and manually that the logs were worklogs were identical. 

The description should say:

When a user logs work for a date that is different from the date when the log entry was added, the CSV export uses the date the log entry was added, not the date the work was done on.

As a result, the export cannot be used for external time reporting as the work shows up being done on the wrong date.  For example, if a developer logs all of their time first thing Monday morning for all of the work for the prior week, all of the work shows as being done on the Monday, not for the previous week.  This leads to curious issues where a developer shows they worked 37.5 hours on one day.  Trippy.