View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0022558 | mantisbt | bugtracker | public | 2017-03-21 10:14 | 2023-07-10 17:08 |
Reporter | rct | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | duplicate | ||
Product Version | 2.2.1 | ||||
Summary | 0022558: Problem with datepicker and custom date format | ||||
Description | Hi, I've noticed a problem when you use custom date format (french here) in the project version datepicker and the due date datepicker. For the project version it fails in the class VersionData method __set on function strtotime (Parse about any English textual datetime description into a Unix timestamp. http://www.php.net/manual/en/function.strtotime.php / the date is not in english format). I dig a little more and I think there is a problem with the date format design: if it is defined at the global level you cannot define a date format matching for example a country because if some users come from another country they will have an unknown date format for them (and if they use another language there are problems with some code using the user language to decode string date format to timestamp). Why not defining those date format in the language files? | ||||
Steps To Reproduce | $g_short_date_format='d/m/Y'; | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
I wonder if this is fixed by 0008957. |
|
Hello, |
|
I Confirm that bug in Mantis MantisBT 2.15.0 When you change date variable $g_normal_date_format in config/config_inc.php
a bug occurs in the project version datepicker |
|
I can confirm that the bug is still in V2.22.0 |
|
Attached you see the same server contacted from 2 different clients. |
|
PR: https://github.com/mantisbt/mantisbt/pull/1587 @rolfiii I'd appreciate if you can test this PR and report back if it fixed the issue you are running into. |
|
Isn't the real problem, that the datepicker creates a format in the localized form, but version_api.php uses "strtotime", which only accepts english dates? Fixed it for me: /core/version_api.php b/core/version_api.php |
|
date_patch.txt (676 bytes)
diff --git a/core/version_api.php b/core/version_api.php index 14b521d..036fa18 100644 --- a/core/version_api.php +++ b/core/version_api.php @@ -111,13 +111,14 @@ class VersionData { if( $p_value == '' ) { $t_value = date_get_null(); } else { - $t_value = strtotime( $p_value ); - if( $t_value === false ) { + $t_date = date_create_from_format( config_get( 'normal_date_format' ), $p_value ); + if( $t_date === false ) { throw new ClientException( "Invalid date format '$p_value'", ERROR_INVALID_DATE_FORMAT, array( $p_value ) ); } + $t_value = $t_date->getTimestamp(); } } } |
|
Still there in 2.24.1, patch still works |
|
in 2.24.2 issue is still there, patch does not work for me..... |
|
Issue still persists in 2.25.2 |
|
Running 2.25.2 and seeing an issue with due_date when we use custom date formats, although our default language is English. I applied the fix in date_patch.txt but it did not help. The symptoms are: Our users consider this behavior as unacceptable because of the loss of data. We will have to stop using the custom date formats (required by our Quality System because we are an international company). |
|
I believe this should be fixed in 2.25.6, see 0031836. If not, feel free to reopen the issue. |
|