x/sys/unix: Can not convert time.Time to Timespec in portable way

[xry111]

What version of Go are you using (go version)?

go version go1.9.2 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/xry111/go"
GORACE=""
GOROOT="/opt/google-go"
GOTOOLDIR="/opt/google-go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build074259031=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config

What did you do?

I want to convert a time.Time to unix.Timespec. But there is no portable way to do that.

What did you expect to see?

We should have a way to convert time.Time to unix.Timespec cleanly.

What did you see instead?

The only factory of Timespec is NsecToTimespec. This certainly lead to year 2262 problem.

Then I tried

// t is a time.Time
ts := unix.Timespec{
    Sec: t.Unix(),
    Nsec: t.Nanosecond(),
}

This fails with type mismatch. More seriously, the types of Timespec.Sec and Timespec.Nsec differ on platforms. Now I have no idea how can I generate a unix.Timespec from time.Time.

[bradfitz]

Seems like a reasonable request. Any proposal what it should on 32-bit systems for times past 2038? Probably just ignore the problem like NsecToTimespec.

/cc @tklauser

[xry111]

I am not sure... There are several plans:

(1) gccgo's syscall package provides Timespec_sec_t and Timespec_nsec_t. Perhaps we can provide them (Go type of C.time_t and C.long) in unix. Maybe also Timespec_sec_limit so users can check 2038 issue.

(2) Provide a convert function TimeToTimespec, and ignore 2038 issue. (In fact I generated such one with go tool cgo -godefs in my project to create Timespecs).

(3) Provide TimeToTimespec returns an error for Times past 2038.

[bradfitz]

gccgo and the gc (golang.org) compiler should not have different syscall packages. That's a big unfortunate if true. (@ianlancetaylor?)

What is Timespec_sec_limit? We don't want to invent new types in these packages. We want to only reflect what the underlying operating system has. (or C library, especially for operating systems where the stable interface is C)

Maybe we can have:

// TimeToTimespec converts t to a Timespec.
// If t is out of range (past ~2038 on some 32-bit systems), the returned Timespec will be bogus.
// Use ValidTimeForTimespec to determine whether t will fit. 
func TimeToTimespec(t time.Time) Timespec { ... }

// ValidTimeForTimespace reports whether t can be converted into a valid Timespec.
func ValidTimeForTimespec(t Time.Time) bool { ... }

Or something.

[xry111]

Yes. I agree with Brad's TimeToTimespec and ValidTimeForTimespec API.

But libgo really generates these strange types...

[ianlancetaylor]

It's unavoidable for gccgo to have a different syscall package. gc pre-generates the syscall package.
gccgo generates much of the syscall package at build time, so that it is portable to different systems. The effect is that the syscall package is almost entirely different.

Gccgo and gc share the same golang.org/x/sys/unix package, of course, although that is a problem sometimes as that package does not work on all systems that gccgo works on.

[tklauser]

Yes, unfortunately the types of Timespec.Sec and Timespec.Nsec are platform-specific. I agree that Brad's suggested TimeToTimespec and ValidTimeForTimespec seem like the reasonable thing to do.

[gopherbot]

Change https://golang.org/cl/82919 mentions this issue: unix: add functions for converting time.Time to Timespec

[tklauser]

BTW, Timeval may also benefit from the same set of time.Time conversion/checking functions.

[nightlyone]

May I suggest a more Go like API?
MustTimeToTimespec which panics with a message telling it is outside the representable range from foo to bar by time.Duration amount.
And TimeToTimespec returning the panic string as a normal error value instead of a boolean.

That way sloppy code will panic instead of behaving funny and the error checking will be as expected.

[bradfitz]

@nightlyone, well... the syscall and x/sys packages aren't really Go-like as is. I view them as the necessary evil gross glue packages that permit higher-level packages to be Go-like. Also, there are very few panics in syscall and x/sys today, and looks like all for programmer error, and not runtime failures that might come from users.

That said, I wouldn't object to MustTimeToTimespec and a version returning an error, but I don't really care if they remain ugly either.

@ianlancetaylor, do you have preferences?

[ianlancetaylor]

I'm personally not fond of Must functions in general. I'd prefer them to stick to initializers for global variables, where the convenience outweighs the ugliness. And I don't think many people will be converting time.Time values to Timespec values in global initializers.

If we want a Go-like approach, let's just have one function, TimeToTimespec, which returns an error value. That would be consistent with existing golang.org/x/sys/unix functions like ByteSliceFromString.