proposal: time.Parse: support letter-based formats, such as "yyyy-mm-dd HH:MM:SS"

[TheCoreMan]

Proposal Details

Previous work and context

This is a continuation of two previous discussions (there might be more, but I haven't found them):

• "time.Parse: why not literals?" by boumboum.
• On the lastest episode of Cup o' Go, we mentioned the (now declined) proposal to add "1136214245" as layout string for unix timestamp. This sparked a discussion of the deep dislike people have for the current time.Parse formats on the #cup-o-go Slack Channel, including the following comments. Keep in mind that the channel is a lot less formal than the proposal process is, so these quotes should be taken lightly:
  • "There are some things I criticized early on in my journey with Go that ended up being really valuable and purposeful limitations. The date time formatting is just objectively bad."
  • "Yeah the time formatting is an awkward wart. It’s located in a place where most people you meet don’t see it, but when they do you feel like you have no excuse…"
  • "I'm not a fan of Go time formatting and this 1136214245 proposal isn't helping me overcome my dislike."
  • "You mean you don't like formatting around an arbitrary date that only makes sense if you've seen it and are from the US?"
  • "I have to agree with the date formatting issues. Being not from the US, my argument isn't that it should be in the world-dominant format, but that it should be YYYY-MM-DD format, though using the US format seems the worst choice for format considering Google is an international business."

Comparison to other languages

I propose we support a layout that's much easier to read and understand, similar to other time format options. Existing references include:

• Python's datetime module format codes
• JavaScript's Luxon's parse/format table of tokens - and as a bonus, the fromFormatExplain is a nice touch for developer ergonomics.
• Java's DateTimeFormatter class.
• Rust's chrono::format::strftime.

All these examples are widely used and, very notably, don't work the same way as we do it in Go.

What do I think we should do in Go, then?

I suggest two options to consider:

Keep the current API and add support for layouts with chars

Which will look like this (I randomly picked the Python letters/format, but we could pick another layout table if we want).

    tm, err := time.Parse("%d/%m/%y %H:%M:%S.%f", "31/01/22 23:59:59.999999") 

Add a "Layout" type to the time.Parse API, similar to how Rust does it

This is a bit cumbersome - but honestly, I've never been able to use time.Parse without having to double-check which parameter is the layout and which parameter is the input. So something like:

myCoolLayout, layoutErr := time.NewLayout("%d/%m/%y %H:%M:%S.%f") // Error if format is bad, e.g. includes unknown letters?
if layoutErr != nil {
    // Handle it however you want, I assume this is almost always a panic
}
myTime, timeErr := time.Parse(myCoolLayout, ""31/01/22 23:59:59.999999"")

[seankhliao]

Duplicate of #40287

[shayn-orca]

@seankhliao can the long list of people who already suggested this, and the feedback, warrant a re opening of this issue?

Bare minimum, if the x-in-std lib argument is a winner, can we update the docs for time.Parse to let people know about the strftime stuff that lives outside the stdlib?

Edit: oops, answered from my Corp account, but I'm the OP 😅

[TheCoreMan]

Not only that, but looking for non-stdlib-implementations, looks like there are many, and non are "dominating". So the same case that was made for keeping YAML out of the STDLIB (see #61023) by @rsc:

On top of that, @niemeyer has done an excellent job writing gopkg.in/yaml.v3, which as the top comment points out is the most widely used YAML package in the Go ecosystem. For that I am incredibly grateful, and I think we should continue to encourage use of that package.

Can't be made here. See: https://pkg.go.dev/search?q=strftime

[seankhliao]

To allow us to make progress, once we've made a decision, we will generally not relitigate without significant new information.

While popularity is a factor to consider, the general lack of popularity of third party packages (relative to recent additions such as http mux patterns or structured logging or non-additions such as yaml) would indicate that it isn't there.

Go generally aims to have a single way to do things, at least within the standard library, and we have one that works for time. While this doesn't preclude the existence of third party packages like strftime, it is a reason for it not to refer to arbitrary outside resources.