Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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" #3793
NuGet pack "The DateTimeOffset specified cannot be converted into a Zip file timestamp" #3793
Changes from 5 commits
1e0437f
57bb207
e45b889
d7bdb3c
18e3bf0
3f11fc4
5c9d833
ede2569
d89fcfb
b212126
146d4e5
7442f7b
dea0eef
bd1c76a
d9e5479
f24aff3
af38361
69161ae
a7f53aa
c5c3ebf
49cc7eb
5d812dc
b7737cb
fa51fa0
9bad83e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my previous round of reviews, I asked to make sure
timeOffset
was in the UTC timezone before settingentry.LastWriteTime
, but I don't see that it's checked or converted anywhere.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just in case I added
.UtcDateTime
. But for actual physical files it's already in UTC timezone and it comes from below call stack.This method calls our above method and passing
lastWriteTime
.NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs
Line 1126 in 49cc7eb
And this one calls above 1 and passing
lastWriteTime
.NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs
Lines 966 to 970 in 49cc7eb
In non-deterministic mode
lastWriteTime
isfile.LastWriteTime
which actually reads UTC datetime here:NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PhysicalPackageFile.cs
Lines 96 to 99 in 74781ba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but
NuGet.Packaging
is a package that customers can reference in their own projects, and by implementing their ownIPackageFile
that does not return UTC time, they could encounter problems. You've fixed it by using.UtcDateTime
, but my point is that since NuGet is not only a tool, but also a package/SDK, we need to consider all the different possible usage.Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.