Last Modified time for zip entries is UTC time

[d3chapma]

I'm in a -4:00 timezone. When I create an archive then extract it, the extracted files have a correct created time, but their last modified times are created time + 4 hours.

If I modify the jszip source to the following, the created and last modified times are the same, which is what I would expect:

    dosTime = date.getHours();
    dosTime = dosTime << 6;
    dosTime = dosTime | date.getMinutes();
    dosTime = dosTime << 5;
    dosTime = dosTime | date.getSeconds() / 2;

    dosDate = date.getUTCFullYear() - 1980;
    dosDate = dosDate << 4;
    dosDate = dosDate | (date.getUTCMonth() + 1);
    dosDate = dosDate << 5;
    dosDate = dosDate | date.getUTCDate();

[dduponchel]

It seems the timestamp is usually stored in local time while time related extra fields (NTFS Extra Field, UNIX Extra Field or Extended Timestamp) use UTC. JSZip currently use UTC for the timestamp and doesn't support these extra fields. Instead of just reverting 9c7e0099e369eef6db44adf124e065d467339946, I'd rather support the extra fields to improve compatibility.

Which archive manager do you use ?

[aaronmallen]

I'm seeing the same thing on mac OSX with CSV files in the zip.

[danny0838]

I recently have this issue, too. It is just annoying that a file compressed by JSZip on my computer gets a wrong lastmodified time after extracted on the same computer. And I have to do the extra code work to adjust the time put and get from JSZip.

In my opinion, if in convention the native zip timestamp is to store the local time, we'd better follow the convention to prevent unexpected results, before the extra fields is supported.

Or, as a compromise, add an option to allow the user decide what to be stored and read.

[jazdw]

In my opinion, if in convention the native zip timestamp is to store the local time, we'd better follow the convention to prevent unexpected results, before the extra fields is supported.

Agreed! I get the wrong last modified time when reading the zip using 7-zip and the Windows Explorer zip reader.

Instead of just reverting 9c7e009, I'd rather support the extra fields to improve compatibility.

It seems like the commit should be reverted and the extra fields should also be supported.

[mooreryan]

Is there a way to get the modified date to match the local time using the API or is the only option to modify the source code?

I passed in { date: new Date() } as on option to the file function, but that didn't do it.

[MEGApixel23]

I've found a workaround for this issue. Consider the following code:

const zip = new JSZip();
const currDate = new Date();
const dateWithOffset = new Date(currDate.getTime() - currDate.getTimezoneOffset() * 60000);

zip.file('path/to/file/filename.txt', 'file content here', { date: dateWithOffset });

If works for file create/modified time but not for folders though.

[ypujante]

I am also having the same issue on macOS. @MEGApixel23 workaround works but I am just not sure why the author of the library is not providing a way to do this natively with the library. Every user of the library seems like they will bump into the same issue (in my case I spent a few hours trying to figure out why my build kept on rebuilding everything over and over, which turned out to be cmake seeing files in the future, hence need to rebuild).

[MEGApixel23]

I am also having the same issue on macOS. @MEGApixel23 workaround works but I am just not sure why the author of the library is not providing a way to do this natively with the library. Every user of the library seems like they will bump into the same issue (in my case I spent a few hours trying to figure out why my build kept on rebuilding everything over and over, which turned out to be cmake seeing files in the future, hence need to rebuild).

Seems like an author would not fix this. That's a great opportunity for adding the fix and create a pull request!

[luchuanbaker]

I've found a workaround for this issue. Consider the following code:

const zip = new JSZip();
const currDate = new Date();
const dateWithOffset = new Date(currDate.getTime() - currDate.getTimezoneOffset() * 60000);

zip.file('path/to/file/filename.txt', 'file content here', { date: dateWithOffset });

If works for file create/modified time but not for folders though.

yes, I have found a better method, it works for both files and folders:

const currDate = new Date();
const dateWithOffset = new Date(currDate.getTime() - currDate.getTimezoneOffset() * 60000);
// replace the default date with dateWithOffset
JSZip.defaults.date = dateWithOffset;

[gadton]

Better than nothing! I'm not the JS expert but I think that solution is not thread-safe, is it?

[agokhale]

This is astonishing behaviour. I've fixed this with this PR: https://github.com/Stuk/jszip/pull/735

[quiethappy]

When will the problem be fixed

[cyfung1031]

@Stuk why don't fix it? The problem addressed since 2016. The solution is already clear in 2019. PR #735 provided in 2021. And now is 2023.

[agokhale]

😂 - thanks for not closing the PR.. But I fear maintainer may have left the building.