https://bugs.kde.org/show_bug.cgi?id=464633
Pedro V <voidpointertonull+bugskde...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |NEEDSINFO
CC| |voidpointertonull+bugskdeor
| |g...@gmail.com
Resolution|--- |WAITINGFORINFO
--- Comment #3 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
