In debian we are trying to update the zip crate to 0.6.x, while we do have a mechanism to package multiple versions of a crate in paralell it is something we try to avoid where possible.
I bumped the dependency and most of the code built fine, but there was one chunk of code that failed.
let mtime = entry.last_modified().to_time().to_timespec();
let mtime = filetime::FileTime::from_unix_time(mtime.sec, mtime.nsec as u32);
zip 0.6 has moved from time 0.1 to time 0.3 and as a result of this the return type of to_time() has changed from "Tm" to "Result<OffsetDateTime, ComponentRange>"
This raises a couple of issues, the first is that OffsetDateTime does not have a to_timespec function, it does however have a unix_timestamp_nanos function which can be used to achieve much the same goal.
The second though, is what to do about error handling. The old code in time 0.1 just blundered on if invalid values were supplied, but the new time 0.3 codepath includes error checking. So that leaves the question of what to do if an error happens during timestamp conversion, should some default value be used or should the error be propagated to the caller.
I've attatched a patch which handles the new API and propagates errors to the caller.
Hi,
In debian we are trying to update the zip crate to 0.6.x, while we do have a mechanism to package multiple versions of a crate in paralell it is something we try to avoid where possible.
I bumped the dependency and most of the code built fine, but there was one chunk of code that failed.
zip 0.6 has moved from time 0.1 to time 0.3 and as a result of this the return type of to_time() has changed from "Tm" to "Result<OffsetDateTime, ComponentRange>"
This raises a couple of issues, the first is that OffsetDateTime does not have a to_timespec function, it does however have a unix_timestamp_nanos function which can be used to achieve much the same goal.
The second though, is what to do about error handling. The old code in time 0.1 just blundered on if invalid values were supplied, but the new time 0.3 codepath includes error checking. So that leaves the question of what to do if an error happens during timestamp conversion, should some default value be used or should the error be propagated to the caller.
I've attatched a patch which handles the new API and propagates errors to the caller.
zip-0.6.txt