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

[wendellestradairely]

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>

2. Execute dotnet build.
3. 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

[viceice]

Seeing this too when updating from version 2.3.4 to version 2.4.0 for net461 exe project.

[viceice]

NuGet/Home#7001

[natemcmaster]

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.

[viceice]

Maybe a dotnet sdk 3.0 / code sign issue?

[natemcmaster]

I'm writing up a minimal repro right now and testing on Windows. Looks like it has nothing to do with code sign. dotnet pack in the 3.0 SDK messes up timestamps.

[viceice]

release was build with preview9, have you tried preview8 or earlier?

[natemcmaster]

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, NuGet/Home#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 NuGet/Home#7395)

cc @nkolev92

[wendellestradairely]

@natemcmaster My time zone is currently set in Kuala Lumpur, Singapore (UTC+08:00). I also tried removing all .net 3.0 preview SDKs and runtimes and still having the same error. I'm not getting an error with CommandLineUtils v2.3.0 though. It seems like a problem specific to v2.4.0.

[viceice]

I'm on CEST time zone (UTC+2)

dotnet sdk: 2.2.401

[natemcmaster]

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

[natemcmaster]

@wendellestradairely @viceice this only appears to reproduce if running dotnet pack with a 2.2 or older SDK. Would it be reasonable for you to upgrade to the 3.0 RC1 SDK? https://dotnet.microsoft.com/download/dotnet-core/3.0

[viceice]

Then i had to upgrade all our build machines, which would be a lot of work.

I'll try to update one of them and pin our ci for that job.

btw seeing this issue on sdk v2.2.402 too.

[wendellestradairely]

@natemcmaster It's fine with me using 2.3 of this library for now. I cant upgrade to 3.0 SDK. There are several 1st party and 3rd party libraries that I'm currently using with my main project that don't currently support 3.0. Thanks for looking into this issue by the way. I'm happy using this awesome library!

[natemcmaster]

I'm working on a fix...standby for testing and validation: #278

[viceice]

ok, installing sdk 3.0-rc fixes the problem.

[natemcmaster]

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.

[wendellestradairely]

@natemcmaster Thank you so much. I'll look forward to the latest nuget package when it becomes available.

[natemcmaster]

https://www.nuget.org/packages/McMaster.Extensions.CommandLineUtils/2.4.1

Happy to help! This was a fun one 😁

[wendellestradairely]

Updated to 2.4.1. Works perfectly!! Thank you. 👍🥇💯

[jzabroski]

Hi @natemcmaster I tried to look into your workaround here, but it seems you moved the file and/or the workaround. I can't seem to find the audit trail linking back to the removal of the workaround. Can you please let me know? It seems like my project is running into this problem. When I diff the unzipped nupkg, the only change I see is the psmdcp file name (but the actual psmdcp files are identical).

<Project>
  <!-- Workaround https://github.com/NuGet/Home/issues/7001 -->
  <Target Name="DisableNuGetDeterministicPackaging"
          BeforeTargets="GenerateNuspec"
          AfterTargets="CoreCompile" Condition="$(RazorLightNonDeterministicPackaging) == 'True'">
    <Warning Text="Disabling Deterministic Packaging" />
    <PropertyGroup>
      <Deterministic>false</Deterministic>
    </PropertyGroup>
  </Target>
  <Target Name="EnableNuGetDeterministicPackaging"
          BeforeTargets="GenerateNuspec"
          AfterTargets="CoreCompile" Condition="!($(RazorLightNonDeterministicPackaging) == 'True')">
    <Warning Text="Enabling Deterministic Packaging" />
    <PropertyGroup>
      <Deterministic>true</Deterministic>
    </PropertyGroup>
  </Target>
</Project>

Run via:

dotnet pack --configuration Release -o .\deterministicPack /p:RazorLightNonDeterministicPackaging=False
dotnet pack --configuration Release -o .\nonDeterministicPack /p:RazorLightNonDeterministicPackaging=True

[natemcmaster]

@jzabroski I think you may be hitting a different issue. The problem I ran into happened with a prerelease SDK. The NuGet team resolved the root cause before releasing .NET Core 3.

[jzabroski]

Got it, thanks for your help. I'm getting closer to figuring it out.