Home: 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]

https://github.com/dotnet/core/issues/3388

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

[nkolev92]

@ChrisMcKee

The issue dotnet/core#3388 is referring to is https://github.com/NuGet/Home/issues/8599.

This is a bug in the same problem space.

[achilleaskar]

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]

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

[vbearn]

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]

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 :)

StackOverflow Link:
https://stackoverflow.com/questions/61029290/nuget-pack-the-datetimeoffset-specified-cannot-be-converted-into-a-zip-file-tim/61056852#61056852

[rwecho]

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

[twenzel]

Found issues for following files:

Name                                                           LastWriteTime       FileVersion
----                                                           -------------       ------------------------------------------------------------------------------------------
Microsoft.Extensions.Configuration.CommandLine.dll             01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.EnvironmentVariables.dll    01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.FileExtensions.dll          01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.Ini.dll                     01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.Json.dll                    01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.KeyPerFile.dll              01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.UserSecrets.dll             01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Configuration.Xml.dll                     01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Diagnostics.HealthChecks.Abstractions.dll 01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Diagnostics.HealthChecks.dll              01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.FileProviders.Composite.dll               01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.FileProviders.Embedded.dll                01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.FileProviders.Physical.dll                01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.FileSystemGlobbing.dll                    01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Hosting.dll                               01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Http.dll                                  01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Localization.Abstractions.dll             01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Localization.dll                          01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Logging.Configuration.dll                 01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Logging.Console.dll                       01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Logging.Debug.dll                         01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Logging.EventLog.dll                      01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Logging.EventSource.dll                   01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Logging.TraceSource.dll                   01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.ObjectPool.dll                            01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Options.ConfigurationExtensions.dll       01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.Options.DataAnnotations.dll               01.01.1980 00:00:00 3.100.19.56504
Microsoft.Extensions.WebEncoders.dll                           01.01.1980 00:00:00 3.100.19.56504
Microsoft.JSInterop.dll                                        01.01.1980 00:00:00 3.100.19.56504

[secana]

I'm running into the issue with dotnet SDK 3.1.101 a dotnet nuget --version gives me 5.4.0.2
I have no idea, how I can pack a global tool now. I've tried it on Windows 10 and Fedora with the same SDK version but the error occurs on both. Can I provide any information that helps to debug the issue?

[alexandrvslv]

For Linux host current workaround: recursively update all files date in project folder after first time build error.
find -print | while read filename; do
touch -d "now" "$filename"
done

[ebicoglu]

My solution:

Run the below Powershell script.
It sets all the invalid DLL dates to 01/01/2000.

gci -path "C:\" -rec -file *.dll | Where-Object {$_.LastWriteTime -lt (Get-Date).AddYears(-20)} | %  { try { $_.LastWriteTime = '01/01/2000 00:00:00' } catch {} }

StackOverflow Link:
https://stackoverflow.com/questions/61029290/nuget-pack-the-datetimeoffset-specified-cannot-be-converted-into-a-zip-file-tim/61056852#61056852

[theolivenbaum]

Any progress on this? Hit this weird issue just today while debugging a dotnet tool project!

[teroneko]

In my case the file Microsoft.Extensions.Logging.Abstractions.dll was affected, it does not belong to my dll's, so I hope for a fix as well. By the way, you can see those "last-written-to-01.01.1980"-file(s), when you publish to filesystem, so I could confirm it was in my case only Microsoft.Extensions.Logging.Abstractions.dll.
I only hope it is not reproducable in CI/CD environments. There is it is quite difficult to correct the time of the dll's just like that. Thanks @ebicoglu, your script helped like a charm.

[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 : https://github.com/dotnet/extensions/issues/2750

[teroneko]

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

[RobertAcksel]

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.

[aersamkull]

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.

[mdee77]

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