Bug 467994

This is related to Bug 185209

This has become an issue for all our office and I think I have a way to reproduce, even if it might not be super generic, it is reliable here.

Steps to reproduce:
pre) Create a directory with a subdirectory with pictures from a camera inside. Those pictures usually have a creation date set but not a modification date set. Most of the cameras create files like that (i.e probably from FAT32 fs or related). 0) Upload it to OneDrive or other captive location.
1) Visit (evil) OneDrive and download the above directory from there.
2) The directory will be downloaded as a zip file.
3) Use Dolphin and visit the location where you downloaded the zip file.
4) Right click on the zip file and select "Extract">"Extract archive here".
5) Check the modification dates of files. It will be set to 01/01/1970 at 00:00 (zero seconds from the Unix epoch).
5bis) The same happens if one uses   $ ark -d <directory>   modification time is set to zero.

OBSERVED RESULT
The modification date set is invalid, there is no way to set it globally, see bug 185209.

EXPECTED RESULT
If date is invalid (i.e. modification date is before creation date, or just set to zero) then ark should set modification date the same as creation date.

Workaround:
If instead of using the context menu "Extract">"Extract archive here" one opens Ark dialog and drag and drops the root zipped directory, then the modification time is correctly set to current time.

Notice that "Extract archive here" is behaving differently, by default, from drag and drop (and this is per-se a glitch to fix IMHO).

USE CASE
This introduces a quite relevant problem. Any local sync service that checks and uses modification time of files to track them will whine at the fast that modification time is set before creation time.  In particular Nextcloud will refuse to sync the aforementioned extracted files remotely considering the modification time invalid. This basically breaks Nexcloud sync. IMHO this makes this small bug quite actual.
I.E.
Directories extracted using the "Extract archive here" context menu option will fail to sync to Nextcloud.
This will happen every time a directory if recovered from an online storage service (in particular in OneDrive, but should happen also in Wetransfer and alike that zip directories on dowload)

SOFTWARE/OS VERSIONS
Windows:  not even in my last day
macOS: not even if i lose half of my brain
Linux/KDE Plasma: Linux debian 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) x86_64 
KDE Plasma Version: 5.27.0
KDE Framework Version: 5.103.0
Qt Version: 5.15.8

ADDITIONAL INFORMATION
Local filesystem Ext4
I do not like MS
Our customers are using OneDrive, so we can't avoid interacting with, eventually and/or intentionally, malformed zip files or located of buggy FS that set modification date to the future.