golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.1k stars 17.68k forks source link

time: add the ability to parse yearDay #25689

Closed bantl23 closed 5 years ago

bantl23 commented 6 years ago

Consider adding in the ability to parse yearDay in time.parse.

Currently there is no way to parse a time with a yearDay value. Consider adding the ability to into the time.parse function.

YYYY = 4 digit year
MM = 2 digit month
DD = 2 digit day
HH = 2 digit hour
MM = 2 digit minute
SS = 2 digit second
DOY = 3 digit yearday

2006-01-02 15:04:05 which can parse YYYY-MM-DD HH:MM:SS

Consider adding in something like this

2006-888 15:04:05 which would be able to parse YYYY-DOY HH:MM:SS

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

go version go1.10.2 linux/amd64

Does this issue reproduce with the latest release?

Feature Request

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

GOARCH="amd64" GOBIN="" GOCACHE="/home/vagrant/.cache/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/vagrant/go" GORACE="" GOROOT="/usr/local/go" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" 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 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build508236003=/tmp/go-build -gno-record-gcc-switches"

What did you do?

N/A

What did you expect to see?

N/A

What did you see instead?

N/A

meirf commented 6 years ago

Is there any standard (for example any RFC) which specifies a day of year? I couldn't find any.

time.Parse:

Predefined layouts ANSIC, UnixDate, RFC3339 and others describe standard and convenient representations of the reference time.

See the emphasis on RFCs in the time constants.

Based on your analysis that it would be the only 3 digit standard, it certainly would be possible and not too hard to parse day of year, but if it's not a standard then it would rarely be used and would needlessly complicate the time code.

deanveloper commented 6 years ago

This is the closest thing I could find to some kind of "standard": https://cals.arizona.edu/azmet/doy.htm

edit: note that this is not a date format. DOY really is nonstandard and (imo) should need to be manually implemented by the programmer

ulikunitz commented 6 years ago

ISO 8601 calls the format ordinal dates. It is reflected in the Appendix A ISO 8601 Collected ABNF of RFC3339 as datespec-yday.

The format may not be widely used, but it is a date format in the relevant international standard ISO 8601.

meirf commented 6 years ago

... if it's not a standard then it would rarely be used...

(I take back this causality comment. I think standardization/usage are orthogonal.)

meirf commented 6 years ago

/cc @rsc

bantl23 commented 6 years ago

While there is a reference to yearDay in both ISO 8601 and RFC3339 as @ulikunitz stated, the original reason for requesting this feature has to do with yearDay pervasiveness in the space industry. Parsing of yearDay is lacking in the time package and I thought that would be something that might be needed/useful as this is built-in in other modern languages.

ianlancetaylor commented 6 years ago

I'm going to turn this into a proposal. The proposal is that time.Parse recognize 888 as matching the day of the year. The number would be parsed and used as a day offset from the start of the year.

Presumably it would also work in time.Time.Format, where it would print time.Time.YearDay().

rsc commented 6 years ago

/cc @robpike

robpike commented 6 years ago

Ugh. But maybe.

rsc commented 6 years ago

I'm not sure this has to happen at all. But if it does, I don't see why it has to be 888. Seems like 002 is fine.

ianlancetaylor commented 6 years ago

Using 002 would change the output of more-or-less meaningful date formats like Jan 002 which currently print a three digit day-of-month. While I don't know why someone would do that it doesn't seem impossible. Using 888 in a current date string seems less likely.

rsc commented 6 years ago

@robpike and I discussed this and agreed to try 002 early in the Go 1.12 cycle. I'll send a CL shortly. After adding this to Format and Parse the obvious hole in the API is some way to take a year+yday and turn it into a year/month/day, short of preparing a string and calling Parse.

gopherbot commented 6 years ago

Change https://golang.org/cl/122876 mentions this issue: time: add support for day-of-year in Format and Parse