resolve version-control timestamp pseudo-version

[wardn]

go mod is reporting errors due to a pseudo-version timestamp discrepancy...

go: github.com/nats-io/[email protected] requires
golang.org/x/[email protected]: invalid pseudo-version: does not match version-control timestamp (2019-08-13T06:44:41Z)

this commit reconciles the timestamp while maintaining the original commit target.

[coveralls]

Coverage increased (+0.2%) to 92.0% when pulling 0f3ca21 on wardn:master into d9c28b6 on nats-io:master.

[kozlovic]

@wardn Thanks, but the previous value was not hand crafted by me, it was the result of a GO111MODULE=on go build. This is a bit scary..

[ripienaar]

https://golang.org/cmd/go/#hdr-Pseudo_versions :(

[wardn]

I can't imagine anyone handcrafting those! This is the first time I've seen that error on a dependency.

[wallyqs]

Thanks @wardn btw what happens when trying with GOPROXY=https://proxy.golang.org?

[wallyqs]

I can't reproduce this locally... might be a bug with Go modules

[wallyqs]

golang/go#32805

[wardn]

The project I noticed the issue on has a dependency on a private repo (GOPRIVATE=...) so it breaks that aspect when I set GOPROXY. I'll try to set up a contrived project to play around with it.

Looking at golang/sys@fde4db3, which is the commit referenced... it was committed "Mon Aug 12 10:24:04 2019", so even accounting for time zones, it's strange that it got an original timestamp of 20190726091711.

[kozlovic]

So when I updated the go.mod, it looks like the rev was updated, but date was not:
f60a8f1#diff-37aff102a57d3d7b797f152915a6dc16

[wallyqs]

@wardn looks like the suggested workaround for this issue is to use replace:

https://tip.golang.org/doc/go1.13#version-validation
golang/go#32805 (comment)

so maybe something like?

replace golang.org/x/sys v0.0.0-20190726091711-fde4db37ae7a => golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a

[kozlovic]

All that being said, I am ok to merge the PR, will look at this a bit more.

[kozlovic]

If I remove the entry from go.mod and then rebuild, I get the same "wrong" version/rev. So I instead put the rev for the latest commit from their repo and rebuilt and seem to be ok. Would you mind doing that (and a mod tidy and mod vendor) and update the PR? I have one ready if you prefer (and I would still reference you and this PR for proper credits).

[wardn]

All good... I'm just glad to have it resolved. Thanks for looking into it!

[kozlovic]

@wardn Ok, the closing this PR in favor of #924. Thanks!