You don't need a predefined constant to parse that date, just write

d, err := time.Parse("2006-01-02", "2020-01-02")

For such a short format, I'm not sure a pre-defined constant would be very useful.

@ALTree
Yes, I do something like this, but it's very strange when we have const for ISO 8601 format for DateTime, but don't have such const for Date type. WDYT? I think, it's pretty common case to resolve and it can be good to add predefined template const

I'm not sure what the exact suggestion is. ISO 8601 defines several different formats: date, time, combined date and time, duration, interval, repeating interval, etc. What precisely do you think we should do?

I often need to parse date (for example: "2019-12-12") to ISO 8601 format. It's pretty unclear for me, why should I define template for it everywhere or create some util function to do this. I think, it will be good to add const that define template for dates in ISO 8601, just for date. WDYT about it?

Why should we add a constant just for ISO 8601 dates, and not for any other aspect of ISO 8601?

I think, it's pretty more common case to parse date, not interval. Anyway, it also can be good to add consts for all aspects

https://github.com/beoran/iso8601/blob/master/iso8601.go perhaps?

However, I noticed that there seems to be no support in the time package for ISO8601 week dates such as 2006-W23, 2006-W23D1 or day dates 2000-234. In particular the week numbers are useful for certain types of planning software.

@beoran thanks, interesting, but here the main sense is to add it to stdlib like it's made in Ruby. it gives a possibility to not load some additional modules just for a 1 const.

As @ianlancetaylor said there's more to this topic than just adding 1 or 2 constants to the 'time' package. Currently, the time package lacks several features to be ISO8601 compatible, and if they add the constants, that would not be sufficient for real ISO8601 support. A separate package may be the best way to get started on designing what this functionality should be.

ok then, can we can discuss here some structure of separate package for date? and need for this package at all? @ianlancetaylor @beoran

@rbUUbr such package should be a third-party package, I don't think anyone was proposing it for inclusion in the standard library. For this reason, this is probably not the right place to discuss it.

Reading the discussion above, it seems that we are not going to add just a "2006-01-02" constant for ISO 8601 dates in the time package, and providing a bunch of constants for every aspect of ISO 8601 is something that should be implemented as an external package, so I think we can close this issue.