Defining a custom "hours per day" other than Gitlab 8 hours produces invalid TIME RECORDS "time" and ISSUES "spent" from Gitlab

That's pretty simple to reproduce.

1. Create a new issue
2. Using a quick-action in a comment, enter:

/spend 1d

2. With gtt output the full data for the created issue, specifying anything else than 8 hours per day. For example,

gtt report [group/project] iid --hours_per_day=7 --time_format [%hours_overall]

The TIME STATS section outputs a total spent and a spent of 8, which is fine.

The ISSUES and TIME RECORDS sections respectively show a spent and a time of 7. Which is NOT consistent with the TIME STATS and with Gitlab.

I tracked down the code, from the regex that extracts added [x] time spent at [y] -

gitlab-time-tracker/src/models/hasTimes.js

Line 85 in e53587a

let timeString = match ? match[1] : (subMatch ? `-${subMatch[1]}` : `-${Time.toHumanReadable(timeSpent, this.config.get('hoursPerDay'))}`);

It calls the time constructor which in turn calls the time.parse function passing the this._hoursPerDay as hoursPerDay argument from the config instead of specifying the Gitlab default 8 hours.

gitlab-time-tracker/src/models/time.js

Line 32 in e53587a

this.seconds = time.parse(timeString, this._hoursPerDay, this._daysPerWeek, this._weeksPerMonth);

Gitlab does NOT support anything else than 1d = 8h and saves the issue time tracking stats in seconds. This means that querying the issue in Gitlab actually tells to everyone that there are a total of 28800 seconds spent on the issue - see total_time_spent https://docs.gitlab.com/ee/api/issues.html#get-time-tracking-stats - not 25200 seconds.

[kriskbx]

Yeah, you're totally right. Thanks for pointing this out. <3
It just released 1.7.38 containing a fix for this!