timestat back and forth is weird

[sductor]

Hi,

First thank you for the work.
My issue is that I find the behavior of a certain function weird.
But maybe this is not a problem with the code but I didn't unerstand how I am supposed to use it.
Here the faulty code:

iapi = new GitLabApi(…).createIssue(26, "test", "yo");
val issue = iapi.createIssue(26, "test", "yo");
iapi.estimateTime(issue.getProjectId(), issue.getIid(), "3mo 2w");

At this point an issue is created but it displays an estimated time of 5 months!

Then

println(org.gitlab4j.api.models.Duration(api.getTimeTrackingStats(issue.getProjectId(), issue.getIid()).getTimeEstimate())))

display 1mo3d8h

Thus I finnd the utilisation really not intuitive
It appears to me that the problem come from the fact that you are using real time value whereas gitlab use a day = 8h etc. But as this is an api for gitlab, I found a pity that you does not use the same standard as gitlab. I imagine that I would have to do a adapter that would go back and forth between your standard and the one of gitlab. But I think this is also a pity since you already ave those variables
as the two first lines of DurationUtils but that are private.

I feel that the project would benefit to:

• adding a second TIME_UNIT_MULTIPLIERS that would meet with gitlab
• use a singleton pattern for accessing to DurationUtil rather than using the plain class
• Parameterize this singleton to choose which unit multiplier it should uses
• Allow to define this parameter (set) in the class Duration

[gmessner]

@sductor
You've simply discovered a bug, GitLab4J-API should be using the same exact time units as GitLab. There is no need allow the selection of the of a different implementation, this implementation needs to be corrected so that it is 100% in line with GitLab. It will be fixed in the next day or so as it is a fairly significant bug.

[gmessner]

@sductor
Can you confirm the following breakdown?
60s = 1m
60m = 1h
8h = 1d
5d = 1w
4w = 1mo

[sductor]

Yep it is what I got on
myserver/help/workflow/time_tracking.md
!

[gmessner]

@sductor
My concern is the final section called "Configuration", it implies that the number of hours in a day can be changed, but I am unable to locate where that is set, do you know?

[sductor]

I don't think it is possible and would be surprised if it was…
Such a configuration would be really error prone… So far as I've searched I did not find anything
Anyway, maybe you can just let a comment on the code if this feature appear in a next version and someone want to use it. Then my singleton approach would make sense… But I don't think it will be usefull now

[gmessner]

@sductor
If GitLab ever allows the changing of hours in a day (both JIRA and TFS allow it), then they will need to pass that setting around with the time estimates or things will very error prone (as you also believe). Passing the hours/day with the time estimate would eliminate the need for a singleton implementation, it would simply be passed as a parameter when parsing and formatting.

I have made the fix and have released version 4.7.8.

[sductor]

I want to reopen the issue, since it seems to have other problems.
Here is the snwe:
'''
val iapi = (…).getIssuesApi()
val issue = iapi.createIssue(31, "test", "yo");
iapi.estimateTime(issue.getProjectId(), issue.getIid(), "2mo");
println(org.gitlab4j.api.models.Duration(iapi.getTimeTrackingStats(issue.getProjectId(), issue.getIid()).getTimeEstimate()));
'''

Whenever I read the issue from gitlab the time is accurate.
However if I create an issue with a time including mo, it will create an issue of 1month and 2 week for each month. Hence creating an issue of 1 month and 1 day results in an issue of 1 month and 2 week and one day and an issue of 2 months rand 1 day results in an issue of 3 months and 1 day.
This affects only month…

[gmessner]

You have discovered an actual bug with GitLab, not this library. When I make time_estimate calls it looks like the set time estimate endpoint considers "1 month" = "30 days". I have validated this by calling the GitLab API directly using Postman.

As you have discovered, if the "mo" (month) duration is used when setting the time_estimate, GitLab will set the time_estimate to "1mo 2w" for every "1mo", so you get the following results:

Set Duration	Result
1mo	1mo 2w
2mo	3mo
3mo	4mo 2w
4mo	6mo
1mo 1w	1mo 3w
1mo 2w	2mo

If I do not use the "mo" duration, everything is fine:

Set Duration	Result
20d	1mo
30d	1mo 2w
4w	1mo
6w	1mo 2w
...	...

The bug with GitLab is that when setting duration, "1mo" = "30d", but when fetching duration "1mo" = "4w" (20 days). What is interesting, is they do not even reference the "mo" duration in the docs at:

myserver/help/workflow/time_tracking.md

[sductor]

I think I have understand the problem.
It seems that you solved it in the last commit, even if I did not understand how. ^^"
Anyway thank you for your hard work
I will wait for the next release on Maven to test all this, as I'm not familiar with compilation from source