Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NuGet pack "The DateTimeOffset specified cannot be converted into a Zip file timestamp" #7001

Open
oskogstad opened this issue Jun 7, 2018 · 19 comments

Comments

@oskogstad
Copy link

@oskogstad oskogstad commented Jun 7, 2018

Details about Problem

Running nuget pack .nuspec fails with the message
"The DateTimeOffset specified cannot be converted into a Zip file timestamp."

It happens with nuget 4.6.2 for a .dll file that has LastWriteTime 31/12/1979 23:00:00 +00:00

image

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
NuGet.exe
version (4.6.2.5055)

OS version (i.e. win10 v1607 (14393.321)):
Windows 10 v 1803 Build 17134.81

Worked before? If so, with which NuGet version:
Works with v. 4.5.1.4879

Detailed repro steps so we can see the same problem

Run nuget pack NuGetDateTimeOffsetIssue.nuspec in the attached sample project
on nuget.exe v. 4.6 or higher.

Or:
Make a class library that includes NuGet log4net.Ext.Json v. 1.2.15.14586
Run nuget spec <lib-name>
Run nuget pack <.nuspec>

Verbose Logs

~/Downloads ❯❯❯ ./nuget\(1\).exe pack -verbosity detailed C:/dev/.../authenticationhost.nuspec                                                                                          
NuGet Version: 4.6.2.5055
Attempting to build package from 'authenticationhost.nuspec'.
The DateTimeOffset specified cannot be converted into a Zip file timestamp.
Parameter name: value
System.ArgumentOutOfRangeException: The DateTimeOffset specified cannot be converted into a Zip file timestamp.
Parameter name: value
   at System.IO.Compression.ZipArchiveEntry.set_LastWriteTime(DateTimeOffset value)
   at NuGet.Packaging.PackageBuilder.CreatePart(ZipArchive package, String path, Stream sourceStream, DateTimeOffset lastWriteTime)
   at NuGet.Packaging.PackageBuilder.WriteFiles(ZipArchive package, HashSet`1 filesWithoutExtensions)
   at NuGet.Packaging.PackageBuilder.Save(Stream stream)
   at NuGet.Commands.PackCommandRunner.BuildPackage(PackageBuilder builder, String outputPath)
   at NuGet.Commands.PackCommandRunner.BuildFromNuspec(String path)
   at NuGet.Commands.PackCommandRunner.BuildPackage()
   at NuGet.CommandLine.PackCommand.ExecuteCommand()
   at NuGet.CommandLine.Command.ExecuteCommandAsync()
   at NuGet.CommandLine.Command.Execute()
   at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args)

Sample Project

NuGetDateTimeOffsetIssue.zip

image

@dtivel

This comment has been minimized.

Copy link
Contributor

@dtivel dtivel commented Dec 7, 2018

The ZipArchiveEntry.LastWriteTime setter enforces a min and max value. This behavior is documented.

A NuGet solution could be:

  • If a value is less than the min value, we could set LastWriteTime to the min value.
  • Similarly, if a value is greater than the max value, we could set LastWriteTime to the max value.

There is precedence for this approach.

@bobbwhy

This comment has been minimized.

Copy link

@bobbwhy bobbwhy commented Jan 9, 2019

I ran across this issue on a Mac OS 10.14 running dotnet 2.2 and nuget 4.8.
My windows and linux machines do NOT have this issue.

can anyone tell me how to do a work around please?
OR at least where is the ZipArchiveEntry.LastWriteTime located?
Is it project wide? system wide?

thank you.

@Zukka

This comment has been minimized.

Copy link

@Zukka Zukka commented Mar 21, 2019

There is a fix for this problem?

@mfkl

This comment has been minimized.

Copy link

@mfkl mfkl commented Mar 21, 2019

Also running into this. Modified date looks like ‎30 ‎November ‎1979, ‏‎00:00:00

@Zukka

This comment has been minimized.

Copy link

@Zukka Zukka commented Mar 22, 2019

Thanks to my colleague Federico for the workaround:
1- Check if there is one or more files with date like 01/01/xxxx 00:00
image

2 - with Total Commander or other tools change the date value, for example in my fix I changed to 01/01/2018.
With Total Commander, select the file, then select menu File-Change Attribute...

image

@mfkl

This comment has been minimized.

Copy link

@mfkl mfkl commented Mar 22, 2019

That's a workaround for the bug, not a bugfix :) Both 7z and nuget need a fix.

@Zukka

This comment has been minimized.

Copy link

@Zukka Zukka commented Mar 22, 2019

That's a workaround for the bug, not a bugfix :) Both 7z and nuget need a fix.

Updated the comment. From fix to workaround ;)

@per-samuelsson

This comment has been minimized.

Copy link

@per-samuelsson per-samuelsson commented Jun 17, 2019

Also hit by this. Running simple dotnet pack on a project file with <PackAsATool> being set, and on .NET Core 3.0 Preview.

Here's the environment:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview5-011568
 Commit:    b487ff10aa

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview5-011568\

Host (useful for support):
  Version: 3.0.0-preview5-27626-15
  Commit:  61f30f5a23

.NET Core SDKs installed:
  1.0.0-rc4-004771 [C:\Program Files\dotnet\sdk]
  1.0.0 [C:\Program Files\dotnet\sdk]
  1.0.3 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.0.0 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]
  2.1.502 [C:\Program Files\dotnet\sdk]
  2.1.505 [C:\Program Files\dotnet\sdk]
  2.1.600-preview-009472 [C:\Program Files\dotnet\sdk]
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.2.101 [C:\Program Files\dotnet\sdk]
  2.2.103 [C:\Program Files\dotnet\sdk]
  3.0.100-preview5-011568 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview5-19227-01 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview5-27626-15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview5-27626-15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
natemcmaster added a commit to natemcmaster/CommandLineUtils that referenced this issue Sep 18, 2019
…users in GMT >0 timezones

Workaround NuGet/Home#7001
natemcmaster added a commit to natemcmaster/CommandLineUtils that referenced this issue Sep 18, 2019
…users in GMT >0 timezones

Workaround NuGet/Home#7001
natemcmaster added a commit to natemcmaster/CommandLineUtils that referenced this issue Sep 18, 2019
…users in UTC >0 timezones

Workaround NuGet/Home#7001, NuGet/Home#8603
@nkolev92

This comment has been minimized.

Copy link
Member

@nkolev92 nkolev92 commented Sep 18, 2019

@rrelyea

With the deterministic work, this becomes a higher priority

@nkolev92 nkolev92 added this to the Backlog milestone Sep 18, 2019
wazzamatazz added a commit to intelligentplant/app-store-connect-adapters that referenced this issue Sep 19, 2019
@nkolev92

This comment has been minimized.

Copy link
Member

@nkolev92 nkolev92 commented Sep 19, 2019

Folks that are hitting this issue, I'd be curious to understand how the assemblies in your scenarios ended up with a 1980 date.

When implementing deterministic pack we set the date for all the files in the package to 1980/1/1 and hitting this issue became more common.

We'd be curious to learn which tooling was used that ended up creating assemblies with those dates.

@wazzamatazz

This comment has been minimized.

Copy link

@wazzamatazz wazzamatazz commented Sep 23, 2019

In my case, I just used the pack target in MSBuild (Visual Studio 2019 16.3 Preview 4 and .NET Core 3.0 RC1 SDK installed). I'm in UTC+2.

@nkolev92

This comment has been minimized.

Copy link
Member

@nkolev92 nkolev92 commented Sep 23, 2019

Thanks for letting us know @wazzamatazz

That means you're in the

When implementing deterministic pack we set the date for all the files in the package to 1980/1/1 and hitting this issue became more common.

group, so we understand the root cause in that specific scenario :)

@ChrisMcKee

This comment has been minimized.

Copy link

@ChrisMcKee ChrisMcKee commented Sep 29, 2019

dotnet/core#3388

Ref the above as it says the issue is resolved in nuget.

@nkolev92

This comment has been minimized.

Copy link
Member

@nkolev92 nkolev92 commented Sep 30, 2019

@ChrisMcKee

The issue dotnet/core#3388 is referring to is #8599.

This is a bug in the same problem space.

@nkolev92 nkolev92 self-assigned this Sep 30, 2019
@achilleaskar

This comment has been minimized.

Copy link

@achilleaskar achilleaskar commented Nov 26, 2019

In my case this error occured because after an entityframework update the dll modified date was 1980. so I found the source of the dll and used BulkFileChanger to update this Date value and this fixed the error for me

@fleed

This comment has been minimized.

Copy link

@fleed fleed commented Dec 6, 2019

Apparently run into the same issue while referencing EntityFrameworkCore 3.1 packages..

image

arturcic added a commit to GitTools/GitVersion that referenced this issue Dec 10, 2019
…ecause of NuGet/Home#7001

This reverts commit 6fc972e.
@vbearn

This comment has been minimized.

Copy link

@vbearn vbearn commented Dec 12, 2019

Having the same error in .NET Core 3.1 (Stable Version)

Produced a lot of files with ModifiedDate of 1980-something

Temporarily fixed it with a PowerShell command (before running dotnet pack in my CI) to update the dates:

dotnet publish
Get-ChildItem -File -Recurse | % {$_.LastWriteTime = (Get-Date)}
dotnet pack --no-build

Hope there'll be a better fix soon

@ebicoglu

This comment has been minimized.

Copy link

@ebicoglu ebicoglu commented Dec 19, 2019

I made a console app to fix invalid dates in a drive.
https://github.com/ebicoglu/FileBulkDateChanger

Usage:
FileBulkDateChanger.exe C:\

Run this tool and forget about this issue :)

@rwecho

This comment has been minimized.

Copy link

@rwecho rwecho commented Jan 17, 2020

Having the same error when I am packing with specified
For a workaround, I change my pc to UTC-Zero time , and clear .nuget cache

@nkolev92 nkolev92 modified the milestones: 5.5, Sprint 165 Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.