Defect #12955

Misbehaviour in estimated time validation

Added by Daniel Felix almost 5 years ago. Updated almost 5 years ago.

Status:ConfirmedStart date:
Priority:NormalDue date:
Assignee:-% Done:


Category:Issues planning
Target version:-
Resolution: Affected version:2.2.2



we've encountered some misbehaviour regarding the estimated timein Redmine.

I've attached an image which shows several bugs, which seems to relate to the validation of this values.

Here is the reference list, how to reproduce this:
  1. Enter 999999999999999999999999999999999999999 on the estimated time, this produce an arithmetic overflow which doesn't raise an error and is automatic set to FLOAT_MAX
  2. Enter 9999999999 (10 times a 9) as estimated time. This should stay 9999999999 but it's getting rounded up to 10000000000
  3. Enter 999999999999 (12 times a 9) as estimated time. This should stay 999999999999 but it's getting down to some other weird value 999999995904, there are missing 4095 hours. This seems to be related to the exponential display. Both are 1E+12. This seems to be related to float. Float isn't the best datatype to use for such values. Consider to change the column datatype to decimal, which is supported in the current database. This is much more precise and haven't such conversion errors.
  4. This is the tryage to get the rounding. This references to 2.
  5. The helper for the estimated time doesn't check the correctness of the string. For example, you can define hours by 2h30m to get 2.5 or 3h5m to get 3.08 as timevalue. But if you enter abc or 3j (misstyped) the string isn't checked. The issue just returns "update successfully" and sets the estimated time to nil. The string should be checked and should raise some error, if the input isn't correct.

Another idea could be, to limitate the estimated hours to some maximum value. An issue with nearly 1 million hours, seems to be wrong. ;-)

Best regards,

estimated_hours_misbehaviour.png (32.2 KB) Daniel Felix, 2013-01-23 11:42

Related issues

Related to Redmine - Defect #12680: Estimated Time value is corrupted Confirmed


#1 Updated by Daniel Felix almost 5 years ago

  • Description updated (diff)

#2 Updated by Jan Niggemann ( team member) almost 5 years ago

I'm quite sure we had a quite similar ticket a couple of weeks / months ago, but I can't find it. It was about time and rounding, and IIRC JPL closed it...

#3 Updated by Daniel Felix almost 5 years ago

Hm really? I haven't found it too. I searched for something like this bevor.

But there wasn't anything which sounds like this.

#4 Updated by Mischa The Evil almost 5 years ago

Jan is referring to issue #12680.

#5 Updated by Daniel Felix almost 5 years ago

  • Status changed from New to Closed
  • Resolution set to Duplicate

You're right Mischa. I close my issue. Thanks for this hint. :-)

#6 Updated by Daniel Felix almost 5 years ago

  • Status changed from Closed to Confirmed
  • Resolution deleted (Duplicate)

Argh... to fast closed.

Point 5 isn't included in #12680.

Also available in: Atom PDF