Incorrect modification time

[sirinsidiator]

Found a small issue with the modified date for archived files. The msdos format expects UTC time, but in the zip writer the local time is used instead: https://github.com/gildas-lormeau/zip.js/blob/master/lib/core/zip-writer.js#L430-L431
Should be this:

	setUint16(dateView, 0, (((lastModDate.getUTCHours() << 6) | lastModDate.getUTCMinutes()) << 5) | lastModDate.getUTCSeconds() / 2);
	setUint16(dateView, 2, ((((lastModDate.getUTCFullYear() - 1980) << 4) | (lastModDate.getUTCMonth() + 1)) << 5) | lastModDate.getUTCDate());

There is also another problem where 7-zip would show and extract an incorrect modification date (e.g. 2022-12-25 11:44 instead of 2021-05-26 21:10), but as it doesn't really matter for my use-case, I haven't investigated any further.

[gildas-lormeau]

I disagree, I don't think the MS DOS format expects UTC time. Moreover, people don't seem to agree on this point, see Stuk/jszip#369 or Stuk/jszip#616 for example.

[sirinsidiator]

Ok. I was actually a bit confused by the way MS describes it here: https://docs.microsoft.com/en-us/windows/win32/sysinfo/ms-dos-date-and-time and the fact that 7-zip wouldn't show the correct date.
I just reinstalled the library to revert my changes and it now works as expected and even 7-zip shows the correct modification time.
Looks like I didn't have the latest version from yesterday which seems to have fixed the problems, so sorry for the inconvenience.

Anyway, thanks for making this library. I'm already loving the fact that it is several times faster than jszip AND doesn't block the UI. ;-)

[gildas-lormeau]

I confirm there were some bugs in the recent versions of zip.js when I added the support of the extended timestamp extra field (which stores the date as a UNIX timestamp). I guess you were affected by one of these bugs. It should work fine now though.
I'm glad you like zip.js, thank you for your support!