Honor the local timezone, fix for #369, stop time travel!

[agokhale]

Since there is no convention for timezones in zips, it's incorrect to assume they are utc. This leads to astonishing behaviour where files are unpacked with different timestamps than they were packed with. (and differs form the command line zip)
The change strips out the explicit UTC calls and relies on the environments' locale.
A test case is included that uses posix style TZ to demonstrate the bug and the fix.

[cyfung1031]

@Stuk

[agokhale]

I'll clean up this for merging ( it's got some old timey conflict weeds ) . .. If there's interest from @Stuk

[agokhale]

nevermind the conflict is trivial and can be binned with -X theirs.

[khalednigrou]

UTC time gives me a past time in UTC+ areas
so i suppose we need to get local time back

[agokhale]

@khalednigrou @Stuk - is there something I need to do to land this?

[kalegd]

Just wanted to share interest in this change and +1 this

[maxwellmattryan]

Is this going to be merged anytime soon...?

[gschadow]

Indeed in ZipFileWorker.js

dosTime = date.getUTCHours();
dosTime = dosTime << 6;
dosTime = dosTime | date.getUTCMinutes();
dosTime = dosTime << 5;
dosTime = dosTime | date.getUTCSeconds() / 2;

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

is wrong. And likewise DataReader.h

    var dostime = this.readInt(4);
    return new Date(Date.UTC(
    ((dostime >> 25) & 0x7f) + 1980, // year
    ((dostime >> 21) & 0x0f) - 1, // month
    (dostime >> 16) & 0x1f, // day
    (dostime >> 11) & 0x1f, // hour
    (dostime >> 5) & 0x3f, // minute
    (dostime & 0x1f) << 1)); // second

wrong. Someone has contributed a fix and that was never taken and then over the years silly little conflicts.