SUMMARY When an archive has folders without timestamps, ark will use a timestamp of 01/01/1970 01:00. This can cause issues with other software (owncloud/nextcloud sync) as the extracted folder timestamp is considered invalid so the folder & contents do not get syncronised until a valid datetime is set. other software like 7zip and peazip do not do this, and appear to set the date to the time of file extraction. STEPS TO REPRODUCE 1. obtain a zip file that includes folders without a timestamp (https://www.thingiverse.com/thing:5027154/files is a specific example). 2. open/extract zip with Ark 3. note the 'Date' field is empty, or 1970 date of folder if extracted. EXPECTED RESULT honour either the valid date if it exists in the zip file, or have the folder timestamp use the datetime at the point of extraction. ADDITIONAL INFORMATION I guess there are a few train of thoughts to what the correct behaviour should be, but personally i don't believe 01/01/1970 would EVER be functionally correct, even if it is technically correct.
Same bugging behaviour on opensuse Leap 15.5. Needs fixing please !
*** Bug 467994 has been marked as a duplicate of this bug. ***
The linked site was possibly changed already. Clicking on "Download all files" gets me an archive with timestamps set to the time the archive was made. Do you still have such an archive which can be used as a reproducer? The zip format is messy, wanted to check whether the timestamp is actually missing (I'm not sure that can actually happen) or it's just set to 0. Without seeing more, I'm leaning towards the possibility that this may not be a (significant?) bug, and Bug #467994 had more info, especially with Bug #185209 being linked there which may be the ultimate desire. The empty "Date" field is still useful information. Let's theorize that the unix timestamp addition is missing. In that case I believe the ancient DOS-based timestamp which is not optional should be used, and according to https://stackoverflow.com/questions/3725662/what-is-the-earliest-timestamp-value-that-is-supported-in-zip-file-format , 1980-01-01 00:00 should be the earlier possible date with that. At least that's what's likely to be the technically correct approach, although I can't fault anyone for being happy enough with just unix timestamps working, not extending the already crazy domain of date and time handling with ancient DOS issues. Regarding the relevance of Bug #185209 , there's generally the problem that there's no invalid timestamp, the minimum (zero) value is just as valid as the maximum, even if some programs either can't handle part of the range (32-bit limitations, signed integer silliness, repurposing "unused" bit) or uses magic values for validity or error (minimum/zero and maximum typically). The DOS minimum of 1980-01-01 00:00 would likely work in your case, but pointing out that as the presence of that ancient timestamp is not optional, technically there's always a timestamp to be used.
I'd agree with your thoughts Pedro V. thanks for your input! looks like I've still got the original zip file i mentioned in the original post. Extracting it now results in another error ("there was an error while extracting....failed to read data for entry: folder/file_within_zip.stl"), but i'm not seeing 1970 dated files either. I re-downloading the zip from the provided link and do not experience the issue any more. In my case, that means the issue was specifically with how thingiverse were generating the zip and not reliably setting an expected date. The issue has been corrected and i'm no longer experiencing the 1970 date with either my old zip from 22-jan-23, or the one i've just downloaded tonight. fwiw, i'm now on Fedora40 KDEspin.