proposal: time: support Colon for fractional seconds

[trbroyles1]

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

$ go version
go version go1.12.7 windows/amd64

Does this issue reproduce with the latest release?

Yes, I can reproduce it on the playground

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

GOOS=windows
GOARCH=amd64
GOHOSTARCH=amd64

go env Output

$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\N555074\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\Development\go
set GOPROXY=
set GORACE=
set GOROOT=D:\Go
set GOTMPDIR=
set GOTOOLDIR=D:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\N555074\AppData\Local\Temp\go-build289214998=/tmp/go-build -gno-record-gcc-switches

What did you do?

Attempt to parse a date/time string containing milliseconds preceded by a colon. Example:
https://play.golang.org/p/eY-B7yU7cbT

What did you expect to see?

Time is 02/12/2019 15:45:48:746

What did you see instead?

parsing time "02/12/2019 15:45:48:746" as "02/01/2006 15:04:05:000": cannot parse "746" as ":000"

[tannerryan]

This is not an issue. Please review the documentation for package time:

A fractional second is represented by adding a period and zeros to the end of the seconds section of layout string, as in "15:04:05.000" to format a time stamp with millisecond precision.

For your example, the format string must be 02/01/2006 15:04:05.000, not 02/01/2006 15:04:05:000. The input string must also be corrected.

Here is your example corrected: https://play.golang.org/p/E46bFklY7L3

[trbroyles1]

I'm sorry but I have to disagree. I reviewed the documentation thoroughly before writing the original issue, and I am well aware that the problem does not occur if a period is used in place of a colon. That was the whole point of the report I filed. The generated file I am processing uses a colon instead of a period. Which is non-standard, I completely agree. But, that's kind of my point. Non-standard things happen "in the wild", and the library needs to be able to handle them.

Yes, I can work around it by doing a search and replace on the colon in the string. That's what I'm doing for now. But the whole point of a format string, is to... specify the format of the string you want to parse. It's seems we've missed the mark if we have cases like that that it is impossible to format for.

Please, I would ask you, give the issue some more consideration before dropping it again. I'm not expecting this will change tomorrow or anything like that, but isn't it better in the long term if the format strings are able to cover a wider variety of cases ?

This general theme seems to be a recurring issue, to wit:
#6189
#27746
#26002

Couldn't some consideration be given to this? Alternatively, maybe this is a plus point for the priority of localization support

[agnivade]

It seems like you want to file a proposal, rather than an issue. And from what I understand, your proposal is very similar to #6189. I'd suggest that you can subscribe to that issue for updates. Or if you feel the colon as a separator deserves its own proposal, please feel free to go ahead and file one.

[josharian]

All the details are here already—reopened and converted to proposal.

[tengattack]

Maybe you can try this package: https://github.com/tengattack/jodatime ;) for arbitrary format

[rsc]

Non-standard things happen "in the wild", and the library needs to be able to handle them.

Unfortunately, many things happen in the wild, and it is not a goal to handle all of them. That would lead to enormous libraries that are hard to learn to use.

[rsc]

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

[djaglowski]

Thank you for considering this further. I very much agree with exactly the sentiment expressed by @trbroyles1 above.

Unfortunately, many things happen in the wild, and it is not a goal to handle all of them.

I believe there is a very specific ask here, which is to make one specific separator configurable. It could likely be limited to a very small set of possible values, perhaps ., ,, ;, :, -.

While it is trivial to write a string replacement, it is a major performance hit when attempting to process millions of timestamps per second, for example.

Admittedly, it should be difficult to justify a general performance hit for all users of time.Parse, but it would seem reasonable to at least explore this use case further before ruling it out. Perhaps there is an implementation that is essentially performance neutral in most cases but also solves #6189, #27746, and #26002.