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

Closed
oskogstad opened this issue Jun 7, 2018 · 33 comments · Fixed by NuGet/NuGet.Client#3793

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

After fix (PR is in review)

Input file for test:
image

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

@dtivel
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
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
Copy link

@Zukka Zukka commented Mar 21, 2019

There is a fix for this problem?

@mfkl
Copy link

@mfkl mfkl commented Mar 21, 2019

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

@Zukka
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
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
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
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]

@nkolev92
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/AppStoreConnect.Adapters that referenced this issue Sep 19, 2019
@nkolev92
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
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
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
Copy link

@ChrisMcKee ChrisMcKee commented Sep 29, 2019

dotnet/core#3388

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

@nkolev92
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
@teneko
Copy link

@teneko teneko commented Jun 8, 2020

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
Copy link

@maciej-izak maciej-izak commented Jun 8, 2020

@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
Copy link

@teneko teneko commented Jun 8, 2020

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

teneko added a commit to teneko/Teronis.DotNet that referenced this issue Jun 13, 2020
…fied cannot be converted into a Zip file timestamp' (NuGet/Home#7001); Disable GitVersion capabilities: Teronis.MSBuild.GitVersionCache needs only the package reference; You can now specify config file and config file evaluation in GetVersionCache-task implemented; Wrapped SimpleExec.NonZeroExitCodeExcetion; Fixed conditionals regarding SemVer 2.0 format; Added missing 'PrivateAssets="all"' to *.Fody packages; The incremental build informations created when generating filesystem package is now deleted when rebuilding
@rob-ack
Copy link

@rob-ack rob-ack commented Sep 4, 2020

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
Copy link

@aersamkull aersamkull commented Sep 9, 2020

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

@jmezach
Copy link

@jmezach jmezach commented Sep 14, 2020

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 added a commit to ezra-bible-app/ezra-bible-app that referenced this issue Sep 21, 2020
This is a workaround for a bug in NuGet.
See NuGet/Home#7001
tobias-klein added a commit to ezra-bible-app/ezra-bible-app that referenced this issue Sep 22, 2020
This is a workaround for a bug in NuGet.
See NuGet/Home#7001.
@tobias-klein
Copy link

@tobias-klein tobias-klein commented Sep 22, 2020

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

@mdee77
Copy link

@mdee77 mdee77 commented Oct 14, 2020

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

@erdembayar
Copy link
Contributor

@erdembayar erdembayar commented Nov 13, 2020

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

@erdembayar erdembayar self-assigned this Nov 13, 2020
@nkolev92 nkolev92 added this to the Sprint 180 - 2020.11.30 milestone Nov 17, 2020
@erdembayar erdembayar removed this from the Sprint 180 - 2020.11.30 milestone Jan 11, 2021
@erdembayar erdembayar added this to the Sprint 182 - 2021.01.11 milestone Jan 11, 2021
@erdembayar erdembayar removed this from the Sprint 182 - 2021.01.11 milestone Feb 1, 2021
@erdembayar erdembayar added this to the Sprint 183 - 2021.02.01 milestone Feb 1, 2021
hrumhurum added a commit to gapotchenko/Gapotchenko.FX that referenced this issue Apr 18, 2022
fcsouzali added a commit to fcsouzali/EFCore.BulkExtensions that referenced this issue May 21, 2022
Problem:
When you install Microsoft.EntityFrameworkCore.Sqlite 3.1.0 you can see dlls without modify date. It cause to "The DateTimeOffset specified cannot be converted into a Zip file timestamp" when you try to pack my program.
Solution:
Update lib version

related problem
NuGetPackageExplorer/NuGetPackageExplorer#269
OrchardCMS/OrchardCore#4477
NuGet/Home#7001
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment