time: cannot roundtrip Parse the Time.String output

[dsnet]

Regression from Go1.8.

On tip, the documentation of Time.String says:

String returns the time formatted using the format string: "2006-01-02 15:04:05.999999999 -0700 MST"

This is misleading since it suggests that the following should work:

time.Parse("2006-01-02 15:04:05.999999999 -0700 MST", time.Now().String())

However, this does not work on Go1.9 since:

parsing time "2017-06-30 17:31:36.969388848 -0700 PDT m=+0.004118679": extra text:  m=+0.004118679

We should done one of the following:

• Say that round-trip parsing does not work and fix the documentation on Time.String to not suggest that the format string is "2006-01-02 15:04:05.999999999 -0700 MST". We can suggest that String is intended only for human consumption and is not meant to be machine readable.
• Or fix the API for Parse, such that the monotonic timestamps can be ignored.

\cc @bradfitz @rsc

[dsnet]

I argue that we should have Parse ignore the monotonic measurements since there is already existing code that assumes that time.Parse("2006-01-02 15:04:05.999999999 -0700 MST", myTime.String()) should work.

[rsc]

The initial report is misleading. The full docs for time.Time.String say:

func (t Time) String() string
    String returns the time formatted using the format string

    "2006-01-02 15:04:05.999999999 -0700 MST"

    If the time has a monotonic clock reading, the returned string includes a
    final field "m=±<value>", where value is the monotonic clock reading
    formatted as a decimal number of seconds.

Are you aware of anyone round-tripping the output of String in production code? I am not. It's a mistake anyway since the String output gives the time zone twice, the second one will override the first one, and it's the less specific of the two.

If there are widespread production uses of String output being fed into time.Parse, let me know.

Otherwise, if someone wants to add to the end of the doc comment that

The returned string is meant for debugging; for a stable serialized representation,
use t.MarshalText, t.MarshalBinary, or t.Format with an explicit format string.

that's fine.

[gopherbot]

CL https://golang.org/cl/47552 mentions this issue.

[dsnet]

SGTM. It was an assumption made by several tests. Fixing them will be easy.