Thanks for the report. I guess VersionUpdateCommand was forgotten in the fix for 0031836. I'll have a look.

EDIT: actually VersionUpdateCommand was added in 0030415 (2.26.0), after 0031836 was fixed (2.25.6).

Hello @filipesantos

I have tried to reproduce the problem, but couldn't. As far as I can tell it is working as expected.

Can you please confirm that you have configured $g_datetime_picker_format as appropriate to match $g_normal_date_format, as explained in the admin guide ?

If not, please clarify the steps to reproduce, including your values for $g_datetime_picker_format and $g_normal_date_format, as well as the date(s) you entered and the actual error you got including stack trace (temporarily set $g_show_detailed_errors = ON; )

Hello @dregad
Thanks for the answer, I'll send the information:

$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';

With these settings representing the Brazilian date format, where first is the day, month and year; When creating a new version everything happens fine.
When editing a version, even without any edits to the form, the date is incorrectly changed. Example:

I created a version at this moment, that is, its date is 03/11/2024 11:00, if I click on change the date is loaded correctly in Picker, but when saving it is inverted to 11/03/2024 11:00, in other words, he changed the day to the month.
If I edit the date to a day pattern greater than 12, the conversion gives an error and the value 1 is set in the database, and then the field is empty. Example: 25/10/2024 11:00.

When analyzing the VersionUpdateCommand.php file, I noticed that when converting date to timestamp it still uses strtotime, which only accepts dates in the US standard.

Sorry for my bad English.

Thanks for the feedback, and don't worry about your English, it is perfectly fine.

I was actually testing with my own local date format, which uses period . as delimiter, and the system works as expected in that case. With / delimiter the behavior is indeed different, as strtoime() defaults to US format (m/d/y). So the problem is reproducible for me now.

As a workaround pending a fix in MantisBT code, you could use . or - as date delimiter.

I believe your proposition to update VersionUpdateCommand is not appropriate, as it was decided not to allow custom date formats from REST API (see discussion in PR https://github.com/mantisbt/mantisbt/pull/1864#discussion_r1065202271, leading to removal of date_strtotime() from the related Commands in MantisBT master-2.25 f6c250af )

I think the change should go in manage_proj_ver_update.php, I'll analyze in more details later.

PR https://github.com/mantisbt/mantisbt/pull/2047

@filipesantos it would be great if you could test the proposed fix and provide feedback, either here or on the GitHub pull request.

Changing target version to 2.28.0 as the change is not so trivial anymore and could potentially introduce regressions.