Ah, t.Format(time.GoString) would not work since we can only do string formatting there and that would likely be insufficient for printing the Location part so it does not need error handling. Still we could satisfy the GoStringer interface.

I'm not really sure that needs to be in the stdlib, it's trivial to implement without t.Format

https://play.golang.org/p/Lzzbd55VBeH

If your struct is

type A struct {
     B time.Time
}

a := &A{B: time.Now()}
fmt.Printf("%#v\n", a)

Suddenly you need to either implement your custom format string for everything, just so you can get at the time.Time, or hack up something like Printf("&A{B: %s}\n", toGoTime(a.B)) to rebuild the struct formatting around your custom element formatting.

More to the point this is why the GoStringer interface exists.

I see your point, you can still easily wrap it but yeah it'd be nice.

https://play.golang.org/p/OhAGAR6bPs4

This mostly makes sense, but it would have to hide the monotonic time if any.

Hi, ping here, I think this would be a very helpful change for Go 1.16, and I would love to work on this if there is interest.

Change https://golang.org/cl/267017 mentions this issue: time: add GoString method

Hi, now that the 1.17 source tree is open, I would be interested in getting feedback on this proposal. I submitted CL 267017 as an idea for how this feature could be implemented, that could hopefully be used as a jumping off point.

This seems reasonable (still).
Will list in the minutes this week.

Does anyone object to adding this?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

The stickiest point I think is how to represent a *time.Location value. The most common cases for a *time.Location - nil, UTC, or Local - are all easy to handle. However the other cases - fixed zones, or Locations that represent values in the timezone database, like "America/Los_Angeles" - are more tricky.

1. One way would be to try to represent it the same way we represent nested pointers in a struct.

   (*time.Location)(0xbadbcde)

   As I understand the runtime, it would be difficult to get the pointer address without importing either fmt (which imports reflect) or reflect directly, to get and then print the pointer address. The time package is not allowed to import reflect as Russ pointed out.

   I suppose we could special case time.Time inside of the fmt package when someone asks for a GoString representation, since fmt is allowed to import reflect, but that seems less than ideal.

2. Another way would be to convert it to a fixed zone, with the offset determined by the instant represented by the time. You lose information here in some cases, because you would be converting something like "America/Los_Angeles" into a fixed time zone with fixed offset.

   time.FixedZone(loc.name, determineOffset(loc))

   If loc is the America/Los_Angeles timezone, determineOffset would return 8*60*60 = 28800 for a time instant in the winter, and 7*60*60 = 25200 for a time instant in the summer when daylight savings time is active.

3. Another way would just be to print a time.Location value with a lowercase name property. This wouldn't compile, but would be no worse than what we print today for %#v, which also does not compile. We'd need to build in logic to escape strings in case the name field has a " or other characters in it that need escaping.

   time.Date(2020, time.February, 31, 23, 59, 59, 0, &time.Location{name: "America/Los_Angeles"}) 
   ./prog.go:9:79: cannot refer to unexported field 'name' in struct literal of type time.Location

4. Another way would be to replace it with time.LoadLocation, which would also not compile because LoadLocation returns two values. I don't think this is a great idea, but thought I'd mention in the interest of completeness.

   time.Date(2020, time.February, 31, 23, 59, 59, 0, time.LoadLocation("America/Los_Angeles"))
   ./prog.go:9:81: multiple-value time.LoadLocation() in single-value context

Of these, I think (3) is best. I don't think it's possible to implement (1) unless I am missing some aspect of the runtime that would make it possible to retrieve a pointer without importing the reflect package.

GoString doesn't have to give exact Go syntax, I don't think. It prints things like 'main.T', which is not going to compile either. So just saying time.Location("NAME") would probably be fine.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

To be clear, I believe the current proposal is to return strings like:

time.Date(2020, time.February, 31, 23, 59, 59, 0, time.UTC)
time.Date(2020, time.February, 31, 23, 59, 59, 0, time.Location("Americas/New_York")

Yes, that's my understanding

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Great, thanks!

I am implementing time.Location("Americas/New_York") now and thinking about the best way to handle cases where the Location field has a double quote character or emoji or other character that needs escaping.

• One solution would be to call strconv.AppendQuote which would add a dependency on strconv in the time package.

• Another solution would be to copy the parts of AppendQuote that we need (we can simplify appendEscapedRune a little bit since we are only invoking it one way) into the time package and use them there.

• Another one would be to copy the parts of AppendQuote that we need into internal/bytealg and then call it from there. Other packages in the standard library call strconv.Quote or strconv.AppendQuote, but all of them also call other functions in the strconv package so this wouldn't save us very much in terms of dependencies or compilation time.

• Or some other solution involving omitting unprintable fields to avoid the need to take a dependency. This is an edge case of an edge case; most times are going to be UTC or Local and most zones in the tzdata database should contain characters that do not need escaping.

I'm not sure how strongly you feel about taking additional dependencies vs. copying code