time: magic number datetime formatting

[shaneHowearth]

What version of Go are you using (go version)?

 $ go version
go version go1.14.2 linux/amd64

Does this issue reproduce with the latest release?

As far as I know

What operating system and processor architecture are you using (go env)?

go env Output

 $ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/shane/.cache/go-build"
GOENV="/home/shane/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/shane/GoLang"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.14/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pt

What did you do?

https://play.golang.org/p/BSBuQKa9ihR
I had a bug in my code that was due to my misunderstanding the date format style; I had the month and the day the wrong way round. The bug was discovered when a day was added, and unexpected results were returned.

It's not a difficult bug to fix, but it's a bug that is caused by something I was taught as a programmer to avoid: Magic numbers.

The reference date used for formatting is a magic number, in order to know how you want the time to be parsed you need to know which number matches up to what value.

Given that Go is 10+ years old, changing that format style will hurt backward compatibility, and there will even be developers that have memorised the style and can spot the bug at a glance. I am not one of those.

I ask that a sister format be created, one that avoids magic numbers and uses human readable words or symbols to convey meaning.

There are the well known YYYY MM DD HH mm ss and %Y %M %D %H %m %S styles, although they have a confusing overlap with Months and minutes. The former of the two also implies the number of digits that will be used to represent the value (thus YYYY is 2006 and YY is 06). The information encoded is (IMO) clearer than the magic number format.

I know it can be done (in fact when I added my comment to a previously raised issue I was pointed to a 3rd party library that does what I think should be a part of the standard library), the only question is, I guess, do enough people agree with me

What did you expect to see?

Days treated as days and months treated as months

What did you see instead?

Days treated as months and months treated as days

[agnivade]

At this point, as you have rightly said, there's a very high cost of adding new features. The cost should be justified with the gain that it gives. Personally speaking, it does not look like having 2 alternate time formats in the standard library is worth it.

In any case, it seems like you are making a proposal rather that reporting a bug. Do you have any specific format in mind, or do you just want anything other than what is there right now ?

The issue as it is right now is not actionable, because it's neither a bug, nor does it propose something specific.

[shaneHowearth]

Hi Agniva
I don't have a solid proposal in mind, and I am not 100% familiar with the process, the manual says to raise an issue here first; the hope is to raise this as an issue and have opinions aired on the subject. I do recognise that having two formats presents possible consistency issues, but the current format is... really bad...

I saw this issue #32651 which was closed with an abrupt "RTFM"

Ian kindly linked me to https://pkg.go.dev/github.com/jehiah/go-strftime?tab=doc which has the following blurb "This is an alternative to time.Format because no one knows what date 040305 is supposed to create when used as a 'layout' string", that package uses the %Y-%M-%D type format, which I don't think encodes as much information as YYYY-MM-DD

[agnivade]

and I am not 100% familiar with the process,

It is specified here - golang.org/s/proposal

This issue has been raised a lot of times already, and it has been declined every time. I understand the pain you are having, and I think using a third-party library is a good compromise that you can use right now. Unless you have a good proposal, I think the chances of changing this look very slim (as you have already surmised from previous evidence).

I am reluctant to queue this for the proposal meeting unless this is proposing a concrete change. Leaving this one up to @robpike / @ianlancetaylor.

Maybe we want to add an FAQ entry because this gets raised every now and then.

[shaneHowearth]

It is specified here - golang.org/s/proposal

It is specified here - golang.org/s/proposal
The proposal process is the process for reviewing a proposal and reaching a decision about whether to accept or decline the proposal.

The proposal author creates a brief issue describing the proposal.
Note: There is no need for a design document at this point.
Note: A non-proposal issue can be turned into a proposal by simply adding the proposal label.

Guess what bought me here :)

This issue has been raised a lot of times already, and it has been declined every time.

That points to a problem (both that it's being raised repeatedly, and dismissed repeatedly)

I understand the pain you are having, and I think using a third-party library is a good compromise > that you can use right now. Unless you have a good proposal, I think the chances of changing this > look very slim (as you have already surmised from previous evidence).

I am reluctant to queue this for the proposal meeting unless this is proposing a concrete change. Leaving this one up to @robpike / @ianlancetaylor.

Maybe we want to add an FAQ entry because this gets raised every now and then.

[lrita]

I think YYYY MM DD HH mm ss and %Y %M %D %H %m %S are another kind magic number also, no difference.

[shaneHowearth]

I think YYYY MM DD HH mm ss and %Y %M %D %H %m %S are another kind magic number also, no difference.

At a glance, though I can tell you that DD-MM-YY is days, months, and 2 digits for years.

I think the equivalent in the current Go style is 02-03-06 (forgive me if I have these in the wrong order, it's not deliberate) The information conveyed in the Go style is sadly lacking, so much so that I looked it up first in order to try and faithfully present the Go version, but am fairly confident that I have got it wrong.

Even assuming I have that right, the numbers just don't communicate anything, they could be related to datetimes, they could equally be a specific date (I understand that that was the intention of the Go team, but a casual reader is none the wiser from the provided information, they're required to look at more code - having said that I know that DD-MM-YYYY are related to dates because they are the initials of the names of those time periods in my native language, although that is a bad thing, the Go magic date that we parse on, is a specific format of a date, only used in a specific part of the world)

[lrita]

Not all languages using DD-MM-YYYY format(e.g. POSIX function strftime() using %F represents YYYY-MM-DD), and a casual reader may does not know DD-MM-YYYY also.

[as]

There isn't much magic in Jan 2 15:04:05 2006 because most items in the reference date are monotonically increasing and its clear what its function is.

January: First month
2: Second day
15: 3PM
04: Fourth minute
05: Fifth second
2006: Sixth year of the new 21st century

You can write down this date and immediately know how to format time in Go, not so much with YyMmDdHhMmSs.

[shaneHowearth]

Not all languages using DD-MM-YYYY format(e.g. POSIX function strftime() using %F represents YYYY-MM-DD), and a casual reader may does not know DD-MM-YYYY also.

I want to be clear here, I'm saying that 02-03-04 is absolutely terrible to decode, and the reason that a genuine proposal hasn't (yet) come from me is that I am well aware that the other formats are imperfect too (I specifically called out that the reason YMD formats are easy for me is because of my native language (English). I wouldn't dare suggest (for example) that it's as obvious for a non-English native speaker).

[shaneHowearth]

There isn't much magic in Jan 2 15:04:05 2006 because most items in the reference date are monotonically increasing and its clear what its function is.

January: First month
2: Second day
15: 3PM
04: Fourth minute
05: Fifth second
2006: Sixth year of the new 21st century

You can write down this date and immediately know how to format time in Go, not so much with YyMmDdHhMmSs.

Sorry, but I immediately know you want Years, Months, Days, Hours, Minutes, Seconds from your YMD example, I cannot see that with 060102030405 in fact, I doubt anyone would look at that string of numbers and know that it has meaning without a LOT more context (yourself included)

[shaneHowearth]

There isn't much magic in Jan 2 15:04:05 2006 because most items in the reference date are monotonically increasing and its clear what its function is.

For the record, month day, time, year isn't an easy (for me) to recall, because in my part of the world date times are day, month, year, time. The order of the date you refer to is alien to me (which is why it's difficult to produce a workable mnemonic).

Also, most programmers I know prefer their dates to be Year, Month, Day, Hour, Minute, Second (because it's way easier to sort) so I would have used that format for a magic date had I thought to go down this path.

[as]

I cannot see that with 060102030405 in fact

Please give an example where you've seen 060102030405 as a date string in the real world. I feel like this is a very uncommon example, so I don't understand why you chose it. This isn't a date string you will see in the real world, here's something more ubiquitous: 2006-01-02 15:04:05