CommandLineUtils: Error when running dotnet pack if my timezone is GMT >0 (e.g. Singapore or Europe)

Describe the bug A clear and concise description of what the bug is. I tried to reference this library to my .NET Core global tool project via dotnet add package but it produces “The DateTimeOffset specified cannot be converted into a Zip file timestamp.” error when running dotnet pack.

dotnet pack
Microsoft (R) Build Engine version 16.1.76+g14b0a930a7 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 53.03 ms for C:\Projects\MyNewCli\MyNewCli.csproj.
  MyNewCli -> C:\Projects\MyNewCli\bin\Debug\netcoreapp2.2\MyNewCli.dll
  MyNewCli -> C:\Projects\MyNewCli\bin\Debug\netcoreapp2.2\MyNewCli.dll
  MyNewCli -> C:\Projects\MyNewCli\bin\Debug\netcoreapp2.2\publish\
C:\Program Files\dotnet\sdk\2.2.300\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(199,5): error : The DateTimeOffset specified cannot be converted into a Zip file timestamp. [C:\Projects\MyNewCli\MyNewCli.csproj]
C:\Program Files\dotnet\sdk\2.2.300\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(199,5): error : Parameter name: value [C:\Projects\MyNewCli\MyNewCli.csproj] 

To Reproduce Steps to reproduce the behavior:

  1. Create a new .net core global tool project and add the package by running dotnet add package McMaster.Extensions.CommandLineUtils
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <ToolCommandName>mynewcli</ToolCommandName>
    <PackageOutputPath>./nupkg</PackageOutputPath>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="McMaster.Extensions.CommandLineUtils" Version="2.4.0" />
  </ItemGroup>
</Project>
  1. Execute dotnet build.
  2. Execute dotnet pack.

Expected behavior A clear and concise description of what you expected to happen. Should be able to package the project as a nuget package.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.2.300
 Commit:    73efd5bd87

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.300\

Host (useful for support):
  Version: 3.0.0-preview6-27804-01
  Commit:  fdf81c6faf

.NET Core SDKs installed:
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.1.700 [C:\Program Files\dotnet\sdk]
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.2.203 [C:\Program Files\dotnet\sdk]
  2.2.300 [C:\Program Files\dotnet\sdk]
  3.0.100-preview6-012264 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview6.19307.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 22 (9 by maintainers)

Most upvoted comments

Haha, wow. I confirmed timezone is the problem on my own machine, too. However, it’s not the timezone of the computer at the time of pack which matters, rather the timezone during restore, which puts the file in your $HOME/.nuget cache.

Let me see if there is a reasonable workaround for this…

I’m working on a fix…standby for testing and validation: https://github.com/natemcmaster/CommandLineUtils/pull/278

I verified a fix locally and have pushed a fix. It will take a few hours for 2.4.1 to propagate to NuGet.org. When that becomes available, please let me know if this issue persists.

The version of NuGet in the 3.0 SDK intentionally removes timestamps when creating the .nupkg file as a part of a new NuGet feature called “deterministic packaging”. Once that .nupkg is extracted on another machine, it appears it can triggering a different NuGet bug, https://github.com/NuGet/Home/issues/7001, which has trouble adding files to a .nupkg which have a timestamp of 1/1/80 or older.

I don’t have a good way to opt-out of deterministic packaging. NuGet turns this feature on using the same MSBuild property$(Deterministic) – is also used for the deterministic C# compiler flag (which I want to keep enabled).

@wendellestradairely I was unable to reproduce this on a clean machine using the 2.2.300 SDK. I’m in the Pacific Time Zone (GMT-7). What about you? I’m wondering if this is issue further affected by which timezone you’re in? If so, we might be seeing the perfect storm of NuGet bugs (cref https://github.com/NuGet/Home/issues/7395)

cc @nkolev92

Strange. I can confirm the timestamp on the files in the .nupkg do not reflect when they were actually created. While I think ultimately NuGet shouldn’t fail to pack because of this, let me see if I can provide a workaround. I’m not sure why I get those strange timestamps in files from a CI build, so this might take a little extra effort to investigate.

image