Commas used as decimal points in Timesheet entries are parsed incorrectly

Products

• Clarity PPM SaaS
• Clarity PPM On Premise

Issue/Introduction

User accounts default to US English locale. If on US English locale a number like 7,5 is used (US English locale uses dot as a decimal separator), this is changed to 75 which is not the number entered and it is wrong. 7,500 would be a valid number in US English format, but not 7,5. The same would be true when using 7.5 on a locale that expects a comma as a decimal separator (and a dot for thousand separator). 


STEPS TO REPRODUCE 
1* Go to Home > Account settings and make sure that English (United States) locale is selected. 
2* Open a new Timesheet (this is true for both Classic and New UI). 
3* Use "7,5" for a given task and day. 
4* Click on save. 

Actual Results: Number gets changed to 75. 
Expected Results: TMA-0113 error should be thrown. 7,5 is not a valid number in US Locale (and it is not equal to 75). 

Environment

This affects all supported releases (16.x+) 

Cause

A Defect had been raised for this: DE35078
After SE (Sustaining Engineering) review, it has been determined the root cause to be a Java method that is called for parsing a number field's value before persisting it to the database.
Based on the Locale passed to it, it strips off the commas (or dots if that is the number separator for that locale) of the passed in number string unconditionally and therefore is not considered an invalid number entry for generating an error.  
 

Resolution

(SE ) Sustaining Engineering decided this bug will not be fixed.