Edit: this is obsolete given edits I made to the original post.

@dmac suggested a simpler alternative to my workaround:

t := time.NewTimer(math.MaxInt64)
t.Stop()

Notice that everything in the time package refers to a Timer as *Timer. It's not used as a value type.

We probably don't want to do anything here.

The caller can use an if statement:

  var t *time.Timer
  for {
       if t == nil {
          t = time.NewTimer(...)
       }
...

@bradfitz sure, t := new(time.Timer) if you prefer. It doesn't change my code examples, as I'm not passing a time.Timer as a function parameter.

What I'm going for is similar to sync.Mutex and sync.WaitGroup.

Another option is to use

t := time.NewTimer(0)
<-t.C

Thanks @fjl; I've updated my post to remove the complex workaround and took your suggestion.

NewClosedTimer() i think is better.

There are two kinds of timer: those with an associated func and those with an associated channel. There is no API to change or decide that detail after the timer has been created. That is, a zero Timer would do nothing at all - call no function and send on no channel - when it expires. We could make a zero timer valid for calls to Reset and Stop, but you'd never know when it went off, so what's the point?

If you need a timer that isn't going off any time soon, initialize with time.NewTimer(525600*time.Minute) (or your favorite long amount of time) and then Stop it. Or use nil, as @bradfitz suggested above.

There's no need for new API here.

@rsc good point, I hadn't considered the AfterFunc/NewTimer dichotomy. I was only thinking of channel timers (not func timers).

I think what I'd want is for Stop to do nothing for zero timers and for Reset to associate a channel-sending function (sendTime, in the code) with the timer. In other words, the effect of

t := new(time.Timer)
t.Reset(time.Second)

would be the same as

t := time.NewTimer(time.Second)

It seems to me that preferring "channel timers" over "func timers" in this way is okay since func timers are much less frequently used, and because the documentation already casts func timers as a special case:

When the Timer expires, the current time will be sent on C, unless the Timer was created by AfterFunc.

Since this has been open for a while and doesn't seem to have any support, I'll go ahead and close for now.

Change https://golang.org/cl/14871 mentions this issue: time: allow Reset be called on uninitialized Timer