[is_taken]

Why not writing a small wrapper around time.Parse?

  func ParsedTimeOrNil(s string) *time.Time { 
   t1, err := time.Parse(time.RFC3339, s)
   if err != nil {
    return nil
   }
   return &t1  
  }

[Cthulhu_]

This is the answer. Write a utility instead of get frustrated with the language; be pragmatic. Same with looking for libraries that do something trivial.

[whalesalad]

I’m used to parsing a date time with things like %Y-%m-%d not the asinine way Go does it.

[abdusco]

If you're using JetBrains Goland, hit Ctrl+Space when you're writing the date layout in `time.Parse`, and it'll suggest you the regular YYYY, MM, dd etc. placeholders. When you pick one, it types in 2006, 01, 02 magic numbers. Here's a GIF:

https://imgur.com/FyCJZvh

That said, I hate this, all the ways it's opinionated and praised zealously for it as the best thing since sliced bread.

[twblalock]

Hiding errors like that is going to make it hard to figure out what is going on as more and more wrappers like this pile up.

If time.Parse is failing, you either have bad input or a bug, right? If you are ok with this failing without even logging the error, something might be wrong with the design.

[jrockway]

Hiding errors saves less than a second of typing, at the cost of making every five minute bugfix a one day bugfix. Don't do it.

You can't build your own programming language inside of Go. If you absolutely cannot mentally handle functions returning an error and you having to type "if err != nil { fix the problem }", you really need to find a different programming language. But, errors happen all the time, and handling them correctly is the difference between an unreliable piece of garbage that randomly fails and software you and your users can trust. There is, unfortunately, no automation around making software reliable.

[twblalock]

Plus, even if you just return an error/bubble up an exception, that is probably better than bubbling up a nil/null value for some of the consuming code to try to dereference.

[jrockway]

Bubbling up is a great option. It is such a good opportunity to capture relevant context that the caller doesn't know about; like the internal state of the method, and the "why" behind making the call. If everyone does this, you can end up with an error message like "handle /ping: health check servers: ping server 1.2.3.4 (3/42): i/o timeout" instead of just "i/o timeout" (which you get if you just lazily "return err"). You see the first error message, and you know you need to adjust the ping function to treat a timeout as a part of the response. You see the second one, and all you can do is scratch your head. It could be anywhere.

(BTW, stack trace proponents... stack traces don't capture loop iterator variables, or "why" you're calling a particular function. But when you write a quick error message with fmt.Errorf, you can include all of those things.)

Software engineering is a job of continuous improvement. Make it really easy to find the right place to target improvements!