As far as I can tell, the only reason to do this would be so that you can compute offsets from a zero time value. I suggest that you simply don't do that. If you want to compare the result of time.Parse without a year, then compare it to the result of time.Parse of some appropriate constant string.

The current behavior is documented and has been documented since Go 1.1, so we would need a really really good reason to change it now.

Elements omitted from the value are assumed to be zero or, when zero is impossible, one, so parsing "3:04pm" returns the time corresponding to Jan 1, year 0, 15:04:00 UTC (note that because the year is 0, this time is before the zero Time). Years must be in the range 0000..9999. The day of the week is checked for syntax but it is otherwise ignored.

Definitely it's a minor thing. It just seemed like an inconsistency between the time.Time zero value and the zero value time.Parse uses. Do you happen to know if there's a good reason for using a different default year in time.Parse when all other fields get filled with the zero value?

I thought maybe a small fix change like this could happen as a part of Go 2. I understand though that it's still not easy to change the standard library behavior.

Thanks for the reply!

time.,Parse does use year 0, so the question is why the zero value of time.Time uses year 1. That was chosen to avoid having a negative year for the zero value in time zones west of UTC.