If you check the source code for the time.Date() function, you'll find that it does indeed normalize the date by calling a private 'norm' function.
So, if you enter a month of 13, it will overflow into January of the following year. My guess is that they thought this was a better solution than returning an error. It's also a convenient way to adjust a date (forwards or backwards) at the same time as you initialize it. Alan On Tuesday, October 23, 2018 at 9:20:29 PM UTC+1, Taras D wrote: > > Yes sorry -1 is a valid year. > > An invalid month is any integer outside of [1,12]. We can always define > month 13 as January if we adopt Z_12, but I expected an error to occur. > Accepting months outside of [1,12] violates the Principle of least > astonishment. > > For comparison, python verifies the month integer: > > ----> 1 datetime.date(2000, 13, 1) > ValueError: month must be in 1..12 > > > So does golang accept these values because: > - a sensible definition exists for values outside of [1,12]? > - for performance reasons? > > Taras > > On Wednesday, 24 October 2018 01:23:35 UTC+11, Volker Dobler wrote: >> >> Why is year -1 invalid and what is an "invalid" month >> given that 13==1 in Z_12? >> >> V. >> >> >> >> On Tuesday, 23 October 2018 16:01:00 UTC+2, Taras D wrote: >>> >>> Hi, >>> >>> I was surprised to find the following worked without any reported errors: >>> >>> t1 := time.Date(-1, 1, 10, 23, 0, 0, 0, time.UTC) // invalid year >>> t2 := time.Date(2000, 13, 10, 23, 0, 0, 0, time.UTC) // invalid month >>> m := time.Month(13) // invalid month >>> >>> What is the rationale in accepting invalid month/year values? >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
