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

[oskogstad]

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

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

After fix (PR is in review)

Input file for test:

Now this file modified in 1959 after packing looks like this:

[dtivel]

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]

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]

There is a fix for this problem?

[mfkl]

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

[Zukka]

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

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...

[mfkl]

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

[Zukka]

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]

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]

[nkolev92]

@rrelyea

With the deterministic work, this becomes a higher priority

[nkolev92]

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]

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]

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]

dotnet/core#3388

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

[nkolev92]

@ChrisMcKee

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

This is a bug in the same problem space.

[maciej-izak]

@teroneko , @theolivenbaum In my case update to newer version of Microsoft.Extensions.* packages (from 3.1.0 to 3.1.4) fixed the problem, see : dotnet/extensions#2750

[teneko]

@maciej-izak Thanks for the advice. I will check it out later.

[rob-ack]

Confirmed. Still happens as described. There are plenty of files microsoft *dlls which do not have a last changed date ('LastWriteTime'). For me all of them have been reference assemblies which i included in my dev packages and which i am skipping now.

[aersam]

For me a problem as well, with dotnet pack, Version 3.1

[jmezach]

I just ran into this issue as well after upgrading from 4.1.0 to 5.7.0. Any idea when this will be fixed?

[tobias-klein]

I would appreciate a fix of this issue. It's currently breaking the Windows build of Ezra Project.

[mbre777]

Still happening - please fix this as it's breaking my CI.

[erdembayar]

I'm interested in this one as my first 'nuget pack' challenge during "Customer sprint".