Code Deploy - Unhandled exception - ZIP does not support timestamps before 1980

[jwarykowski]

Overview

When running a deployment via circle-ci we've recently been getting the following error when running the create_application_revision command:

Unhandled exception
ZIP does not support timestamps before 1980

I couldn't find an existing issue with the repo. We haven't changed any configuration recently. This appears to have only started happening since yesterday, it was the first time we had the error on our builds.

We're running the following versions:

aws-cli/1.11.97 Python/2.7.6 Linux/3.13.0-48-generic botocore/1.5.60

If anyone is able to point us in the right direction that would be greatly appreciated.

[mgibas]

Same error for:
aws cloudformation package ...

Uploading to a5902e46b3516ee3f44caf6251079b5f  1846 / 1846.0  (100.00%)
Unable to upload artifact ./../async-handlers/donation-created-handler referenced by CodeUri parameter of DonationCreatedHandlerFunction resource.
ZIP does not support timestamps before 1980

even after downgrading to 1.11.79 (that was working some time ago) gives the same error.

full build log

[JordonPhillips]

It sounds like you have some files with invalid timestamps. This could be indicative of a larger issue, so I would recommend fixing them. Changing your version of the CLI won't impact this because the the error is raised in python itself.

[arsenio]

I'm noticing the exact same error message with CircleCI today, during the create_application_revision command:

create_application_revision loaded: {"applications":[{"region":"us-west-2","application_root":"/","revision_location":{"s3Location":{"bucket":"<BUCKET>","key":"<BUCKET_KEY>"},"revisionType":"S3"},"deployment_group":"staging","application_name":"<appname>"}]}
Bundling <appname> from /home/ubuntu/<appname>
Unhandled exception
ZIP does not support timestamps before 1980

((create_application_revision "/tmp/codedeploy_applications.json" "/tmp/codedeploy_revisions.json")) returned exit code 1

[arsenio]

There's also a Bug Report open on CircleCI's support forums about this.

[jwarykowski]

@JordonPhillips thanks for the quick feedback. We'll wait to see if anyone gets back to us on the CircleCi issue. @arsenio -just to note we deployed manually via code deploy directly and this solved the problem in the short term.

[mgibas]

So for me uglify-js got files with creation date at 1969.
As a workaround I added this:

find ./dist/ -type f -exec touch -t 201601011200 '{}' \;

[completer]

This is happening for us too; since Sunday on our Shippable build server and locally after a rm -rf node_modules

eb deploy
Creating application version archive "app-bce1-170606_163952".
ERROR: ValueError :: ZIP does not support timestamps before 1980

This is a nodejs app, EB CLI 3.9.0 (Python 2.7.1)

Update: Looks like this is being caused by uglify-js as @mgibas says.

[arsenio]

@mgibas with the save: certain (but not all) files in the ugllify-js library have 1969 timestamps on them. Touching those files should get your past this nasty hurdle.

[completer]

Actually seems to me to be a prob with Webpack's NPM package. Posted issue webpack/webpack#5022

[mgibas]

Yeah, seems like uglify is a pretty common dependency :)

mishoo/UglifyJS#2054

[et304383]

@sumothecat it's not Webpack's issue. It's an issue with UglifyJS which webpack uses. The community needs to point fingers in the correct location as has been linked by @mgibas

[completer]

@eric-tucker we don't use Uglify, but Webpack has an implicit dependency on it. I've closed the issue in Webpack and will be using a yarn lock file in future!

[felipekm]

Same here, any thoughts?

[brendanmh]

For my application, both jest and webpack were bringing in the corrupted version of uglify-js.

As I already use npm-shrinkwrap, I added the following lines to my npm-shrinkwrap.json file -

"uglify-js": {
      "version": "2.8.27",
      "from": "uglify-js@=2.8.27",
      "resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.27.tgz"
    },

which let me work around this issue temporarily.

[goodanthony]

Looking at mgibas answer, temp solution that worked for me for now after a yarn install or npm install is.

find node_modules/uglify-js -print -exec touch {} \;

[moshest]

More robust hack to add to your package.json file:

{
  "scripts": {
    "install": "find ./node_modules/* -mtime +10950 -exec touch {} \\;"
  }
}

This will touch each file that is more then 30 years old after each npm install command.

[joguSD]

Is anybody still having this issue?
The bug in NPM corrupting the mtime has since been fixed.
And a new version of UglifyJS has been published.

[seibar]

Also appears to be an issue with the ieee754 module, which is a dependency of aws-sdk. This issue has been reported: feross/ieee754#17

[aheld]

seeing the same issues, cause by @slack/client npm this time.

[cazzer]

Though there is definitely an issue with some timestamps getting mangled, I don't see why this CLI tool should care. What is the reason for invalid timestamps causing this issue? Is there a way they can be supported to entirely avoid this issue?

[KonstantinKolodnitsky]

I had the same issue. I tried everything, but only restarting my laptop did the trick.

[rus-yurchenko]

Same issue and it's not an uglify-js issue since I have a latest version of this lib.

[asifashraf]

as suggested above i just ran
find ./node_modules/* -mtime +10950 -exec touch {} ;
on vscode terminal from root dir of the proj and it fixed it

[vochicong]

eb deploy gave me

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
solved the problem.

[einnjo]

This has been a recurrent issue on multiple proyects with different dependencies.

[georgschlenkhoff]

I still run into this issue.

[matthoang08]

Just had this issue too when I added nyc (istanbul) as a dev dependency, it looks like it added uglify-js which is the root cause of this issue.

[cyrilhamidechi]

From my PoV, it seems related to yarn on Mac.
When using npm on Mac everything's fine.
When using yarn on Ubuntu everything's fine.
Even with uglify-js and many other dependencies.
It can be demoed by packaging the hello-world of AWS SAM (https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda).
Else, #2639 (comment) do perfectly the trick (but can be costly with many files)

[kpx-dev]

We use yarn --production that skip all the devDependencies packages, it helps solved this problem.

[cazzer]

Sadly, I depend on a few packages in production which cause this issue so yarn --production doesn't help.

That said, yarn --production before fixing timestamps in node_modules/ does significantly decrease build time.

[albertkimdev]

What is the windows command for

find ./node_modules/* -mtime +10950 -exec touch {} \;

I can't run this on my computer

[eduardomourar]

It looks like this could have been fixed by using the strict_timestamps argument from zipfile python library.