The behavior I infer from the "Possible Solution" is simple modular arithmetic and it's directly supported by the language with no need for conversions: https://play.golang.org/p/v6XOucCpgUW.

Also, I don't see enough value in having the two special cases, prev and next, explicitly handled by extra functions/methods of the time package.

cznic i see enought logic in your snippet of code... i leave up to you the decision to implement it as an function or not in the future releases of golang. It was only my humble suggestion and i think my words were very clear. i don't see why not, neither also you explain to me why not.

func prevWeekday(d time.Weekday) time.Weekday { return (d - 1) % 7 }
func nextWeekday(d time.Weekday) time.Weekday { return (d + 1) % 7 }

and please, you want to every person (in every project) write these two functions over and over again?

is not my way to feel how "we must avoid to rebuild the whell", i insist to reflect on this cznic.

also reconsider the fact that we rely on abstractions in order build bigger system... so, nextWeekday and prevWeekday are part of those abstractions... after all, to implement a function like that in golang i have study before the golang convention for weekdays values (implying to be aware of any convention changes) and that take me time... so i only want to spare some time to others so they (as i) can spend it in more important things that are "above" this problem's domain. Just try to stay focus on our natural task: build abstrations, the right ones; and recall is not about complexity.

FTR

today := time.Now()
tomorrow := today.Add(time.Duration(24) * time.Hour) // adds a day duration
tomorrowWeekDay := tomorrow.WeekDay()

is not a correct solution of the problem.

i believe it works fine (and it does in prod) https://play.golang.org/p/lxbPySc8amm... i encourage you to explain why this is not a correct solution.

The duration between weekday changes is not fixed at 24 hours in the general case.

See also #19700.

As @cznic notes, you can already iterate over weekday constants using the usual mathematical operators, and the expression (d + 1) % 7 is not much boilerplate at all: you don't even need a function to abstract over it. For the general case, the combination of (time.Time).AddDate and (time.Time).Weekday also allow for iteration by arbitrary numbers of days.

For the specific problem of iterating over sequential days, this proposal doesn't seem to carry its weight: it would add API surface for trivial mathematical operations. For less-trivial use-cases, #19700 proposes a more comprehensive API. I'm closing this issue as a duplicate of that one.

bcmills if i understand you right, you stated that it shall not be included because it is very simple logic. If that the case, let me point out clearly that we have diferent point of views here... i don't even put in trial the complexity of the algorithm, neither i care about how it is implemented. Please try to read "Context" section and please answer having in mind those points. I would appreciate very much that feedback, as a college or coworker point of view.

Thanks you both (also cznic) for the reading and the feedback.

New API always carries a cost. If we add a Next method to time.Weekday, we have to document it and maintain it. We also probably have to add a Prev method. The code is easy to write yourself, so as bcmills says this doesn't seem to carry its weight.

thanks for the reply ianlancetaylor. Allow me to highlight a previous question

¿do you want every person (in evey project) write these two pair of functions?

func prevWeekday(d time.Weekday) time.Weekday { return (d - 1) % 7 }
func nextWeekday(d time.Weekday) time.Weekday { return (d + 1) % 7 }

I mean, i know that is very light work to do, but as far i stated this could be a problem to more than one client of the library, so, the question i would make myself as client of the library is ¿why delegate the weigth to each client instead of putting it in a single place (like the "time" library) and once for all?.
I know is work to do and impacts on augmenting the complexity (just a bit, ok! is a bit and is annoying perhaps you may say) of the library; so that is why at first place my proposal was formally expressed among with a helpful (i hope) snippet of code. To recap: The "complexity" exists, and it shall be encapsulated in a layer. Is not an easy matter, it can has a lot of discussion, going and backs. As you can see, i'm participating on this, not only to help the comunnitty, also trying to obtain feedback that could be useful for myself and improve my way yo work with teams.

Encapsulation of complex expression and/or logic often makes sense. Encapsulating trivial expressions (two operators, single non-constant operand) not so much.

There is probably a lot if similar one-liners out there. Never will they all end in the stdlib, so someone must decide where to draw the line.

So we all recognize that the complexity exists and is fact (regardless the level of complexity).
If we put this in "client"/"server" terms: as a client you understand that i would strive for the "server" to implement it (and releases me from the burden that it takes), and i know that this is work for you by relieving me from do it. Allow me to add that i have already make the work, so you can imagine that this doens't release me from anything at this time, but i understand, and very weel, of the importance of this decision.

I see that neither any of my motivations (explained in the Motivations and Context Sections) is not enough to promote this "issue/request" to a "nice to have feature", and is OK. I do have interest of knowing what do you think of each of one of them, without any rush to answer, of course.

I do not know with how many work you have to deal with day by day, but for a start i will assume that is a lot. So I don't want to be annoying with this, and, if i'm about to be it, please excuse me. Thanks

I think I would summarize your motivations and contents as saying that these new methods would be useful. I agree. Nobody would propose ideas that aren't useful.

From my perspective, every change has both a benefit and a cost. We make changes where the benefit is larger than the cost. You've discussed the benefit. The various replies to you above discuss the cost.

In other words, we agree about the benefits you've mentioned. Where we disagree is whether the benefits are worth the cost.

And let me add that I believe that you guys are the ones that know the tradeoff of this, i mean, the cost and the benefits.

Thanks ian, for your feedback, it was very useful to me in order to understand better what is really the matter here, and therefore the thing that, perhaps, may be put on the table for discussion someday.