Defect #3107
Issue with two digit year on Logtime
| Status: | Closed | Start date: | 2009-04-02 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Jean-Philippe Lang | % Done: | 0% | |
| Category: | Time tracking | |||
| Target version: | 2.3.0 | |||
| Affected version: | 2.2.2 | Resolution: | Fixed |
Description
I entered a two digit year in Logtime. The result was that the year showed up as 0009 instead of 2009.
I am using Redmine 0.8.0.devel.2643 (MySQL)
History
#2 Updated by Jean-Philippe Lang about 4 years ago
That's how the ruby Date#parse method behaves:
irb(main):003:0> Date.parse("09-02-04").year
=> 9
irb(main):004:0> Date.parse("2009-02-04").year
=> 2009
I don't know if it's worth hacking it.
#3 Updated by Nanda Palaniswamy about 4 years ago
If possible, Lock the date fields from entering the values manually & let the user to select from the Calendar control will prevent this issue.
In my observation, most of the users are using the Calendar control.
#4 Updated by Daniel Felix 3 months ago
- Status changed from New to Confirmed
- Target version set to Candidate for next minor release
- Affected version changed from 0.8.0 to 2.2.2
This is still reproduceable. I checked this and can confirm this on current trunk.
Jean Philippe wrote:
I don't know if it's worth hacking it.
The validation should be improved or the datefield should only allow 4 digit years. The method doesn't need to be hacked. But it should be validated in the correct way to prepend such an entry.
I set it as a candidate for the next minor release as this could cause misleading timelogs.
#5 Updated by Jean-Philippe Lang 3 months ago
- Status changed from Confirmed to Resolved
- Assignee set to Jean-Philippe Lang
- Target version changed from Candidate for next minor release to 2.3.0
- Resolution set to Fixed
Fixed in r11472. Same validations than issue start/due dates are applied and "09-02-04" is no longer considered as valid.