You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I zip a file from the iOS filesystem (log file). I then read that file as data and send it as an attachment in an email. When I receive the email, the zip file itself has the correct timestamp, but when I extract the zip, the enclosed file has a timestamp that equates to UTC (i.e. tomorrow for me, US Mountain time)
Steps to Reproduce
Create a file in iOS
Zip the file
Send the file
Extract the file
Observe the modification time of the file.
Expected Results
The timestamp of the extracted file should be in your timezone if originator and recipient are in the same timezone
Actual Results
The timezone is "tomorrow", 7 hours ahead, which is my UTC offset.
func onSendLogfile() {
let sourceURL = Utils.LogFileUrl()
let zipURL = Utils.ZipLogFileUrl()
// Zip log file
do {
try FileManager().zipItem(at: sourceURL, to: zipURL);
// Read entire file into a data object.
let zipData = NSData(contentsOfFile: zipURL.path) as Data?
if let zipData = zipData {
mailData = ComposeMailData(subject: "This is a zipped log file",
recipients: ["somebody@me.com"],
message: "Please add additional information as needed to help us identify the issue.",
attachments: [AttachmentData(data: zipData, mimeType: "application/zip", fileName: "arc.logz")])
}
}
catch {
}
showMailView = true
}
Thanks for reporting this with a detailed example.
The ZIP format has very limited support for preserving date and time information of files. It doesn't offer a field to store time zone information so the archiving library can only assume that the stored timestamps are in the local time zone (or store that information elsewhere - e.g. in a separate file within the archive). (https://en.wikipedia.org/wiki/ZIP_(file_format)#Structure).
Some applications and frameworks store the "creation" time zone in an extra field, but there is no idiomatic way to store that information in an archive entry.
Implementing the "Extended Timestamp Extra Field" would work for me. If you can provide a PR, I can review it and try to get it into an upcoming release.
Activity
svenyonson commentedon Jan 12, 2022
Code for above:
`
`
weichsel commentedon Jan 12, 2022
Hi,
Thanks for reporting this with a detailed example.
The ZIP format has very limited support for preserving date and time information of files. It doesn't offer a field to store time zone information so the archiving library can only assume that the stored timestamps are in the local time zone (or store that information elsewhere - e.g. in a separate file within the archive). (https://en.wikipedia.org/wiki/ZIP_(file_format)#Structure).
Some applications and frameworks store the "creation" time zone in an extra field, but there is no idiomatic way to store that information in an archive entry.
svenyonson commentedon Jan 12, 2022
It looks like this has been addressed for other archivers?
https://trac.edgewall.org/ticket/11162
weichsel commentedon Jan 13, 2022
Implementing the "Extended Timestamp Extra Field" would work for me. If you can provide a PR, I can review it and try to get it into an upcoming release.