Time parse error in Golang (parse string to date format)

I am trying to parse the time from a string in Go lang, but it shows the error shown below. Can someone please explain what I'm doing wrong?

Code snippet:

date := "2023-02-20T17:16:51.535133Z"
fmt.Println("date ", date)
date_parsed, err := time.Parse("2023-02-20T17:16:51.535133Z", date)
fmt.Println("date_parsed ", date_parsed)
if err != nil {
		fmt.Println(err)
		return
	}

Output:

date  2023-02-20T17:16:51.535133Z
date_parsed 0001-01-01 00:00:00 +0000 UTC
parsing time "2023-02-20T17:16:51.535133Z" as "2023-02-20T17:16:51.535133Z": cannot parse "-02-20T17:16:51.535133Z" as "3"

Elements of the layout must use the documented reference times to be recognizable.

> Each element shows by example the formatting of an element of the reference time. Only these values are recognized.

Year: "2006" "06"
Month: "Jan" "January" "01" "1"
Day of the week: "Mon" "Monday"
Day of the month: "2" "_2" "02"
Day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"

In other words:

1. Month
2. Day of month, day of year.
3. Hour
4. Minute
5. Second
6. Year
7. Time zone

And fractions of a second are 9's.

Your layout is 2006-01-02T15:04:05.999999Z. You can also use the existing time.RFC3339Nano.

The answer is that your datetime format isn't actually a format; it's the datetime itself. There are particular values you have to give for each field for the time package to know what field is the year, hours, mins, etc. You can see it in the Layout constant in the time package documentation:

Layout      = "01/02 03:04:05PM '06 -0700" // The reference time, in numerical order.

At a slightly more meta level, the layout string would be entirely pointless if you could pass in the time you are trying to parse as the layout. It would rely on the time package knowing the format of the datetime string you are trying to parse in order to parse the layout string, which would then be used to parse the datetime string -- so then why would the layout string be needed at all, if time knew what you meant without you telling it? Not only would it make this field redundant, but it would also remove a huge amount of flexibility to parse a datetime string in whatever format you want. If you could just pass in 01/01/01 to parse 10/02/23 as Feb 10, 2023, how would you parse a date in the American format with MM/DD/YY? Or how would you parse 02/12 to mean Feb 2012 rather than Feb 12 or Dec 2?