View Issue Details

IDProjectCategoryView StatusLast Update
0022558mantisbtbugtrackerpublic2023-07-10 17:08
Reporterrct Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionduplicate 
Product Version2.2.1 
Summary0022558: 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.
One fails with ERROR_INVALID_DATE_FORMAT and the other ignore the due date.
It seems to be ok when I let the default english date format.

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).
For the due date the problem also comes from the strtotime function in the bug_update.php.

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';
$g_normal_date_format='d/m/Y H:i';
$g_complete_date_format='d/m/Y H:i';
$g_datetime_picker_format='DD/MM/YYYY HH:mm';

TagsNo tags attached.
Attached Files

Relationships

duplicate of 0031836 closeddregad Date conversion fails when editing a project version using a non-US date format 
has duplicate 0026906 closeddregad Due_date_default setting is not populating when specific normal_date_format configured 

Activities

vboctor

vboctor

2017-03-21 22:01

manager   ~0056156

I wonder if this is fixed by 0008957.

rct

rct

2017-05-04 07:25

reporter   ~0056772

Hello,
Any update on this?
Romain

JPK

JPK

2018-10-30 14:23

reporter   ~0060880

Last edited: 2018-10-31 12:08

I Confirm that bug in Mantis MantisBT 2.15.0

When you change date variable $g_normal_date_format in config/config_inc.php

   # --- date format settings --------
   # date format strings defaults to ISO 8601 formatting
   # go to http://www.php.net/manual/en/function.date.php
   # for detailed instructions on date formatting
   $g_normal_date_format   = 'd/m/y H:i';

a bug occurs in the project version datepicker
To resolve that, we modified the file manage_proj_ver_edit_page.php
line 103 :
remplace string_attribute( date( config_get( 'normal_date_format' ), $t_version->date_order ) )
by string_attribute( date( "Y/m/d H:i", $t_version->date_order ) )

01-version-date-picker.png (105,176 bytes)   
01-version-date-picker.png (105,176 bytes)   
ralfiii

ralfiii

2019-09-25 10:00

reporter   ~0062906

Last edited: 2019-09-25 10:01

I can confirm that the bug is still in V2.22.0
JPKs solution works just perfect.
Only "real" quote-characters need to be used instead if the quot-html-stuff

ralfiii

ralfiii

2019-09-25 10:40

reporter   ~0062907

Attached you see the same server contacted from 2 different clients.
Date on right client totally spoiled.
Again, JPK's solution resolves that here.

a.png (31,105 bytes)   
a.png (31,105 bytes)   
syncguru

syncguru

2019-12-07 18:15

developer   ~0063193

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.

polzin

polzin

2019-12-11 16:16

reporter   ~0063255

Last edited: 2019-12-11 16:20

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
remove
$t_value = strtotime( $p_value );
if( $t_value === false ) { ...
insert
$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();

polzin

polzin

2019-12-11 16:20

reporter   ~0063256

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();
 					}
 				}
 		}
date_patch.txt (676 bytes)   
polzin

polzin

2020-05-28 15:20

reporter   ~0064034

Still there in 2.24.1, patch still works

cas

cas

2020-12-12 09:52

reporter   ~0064787

in 2.24.2 issue is still there, patch does not work for me.....

alucarddelta

alucarddelta

2022-02-24 01:07

reporter   ~0066297

Issue still persists in 2.25.2

bmason

bmason

2022-03-04 11:10

reporter   ~0066329

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:
1.) When submitting a new bug, the default value set by $g_due_date_default is ignored.
2.) When you do an update, the previously-set value for due_date is cleared. If the user does not reselect a date, the update stores the due_date with a value of "1".
3.) When you do a change status, the previously-set value for due_date is also cleared.

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).

dregad

dregad

2023-06-25 11:45

developer   ~0067864

I believe this should be fixed in 2.25.6, see 0031836. If not, feel free to reopen the issue.