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.