I feel sure that this has come up before, but I wasn't able to find an earlier issue.

We have historically rejected this because not all days are 24 hours. At a daylight savings transition there are 23 hour days and 25 hour days. While for many uses 24 * Hour is the correct value, that is not always right. By not defining Day, we force people to consider exactly what they need.

Thanks @ianlancetaylor – I see the logic now, and I'm glad it's documented here.

If the goal is to force people to consider what they need, then I feel like it's rather ineffective way to go about it. More prosaically, I'm not sure typing 3 * 24 * time.Day instead of 3 * time.Day brings up any DST consideration in my mind, but I may be biased by only dealing with UTC.

Duplicate of #11473

@seankhliao – The duplicate is not open for discussion, and seems restricted to collaborators.

@seankhliao Thanks for finding the earlier issue.

@mohamedattahri Our general approach is that once we've made a decision, we don't change that decision unless there is new information that we didn't consider. If we don't follow that policy, we will be get into an endless loop of discussing older decisions, and won't have any time to make any forward progress.

So if you have new information, by all means share it here and we can reopen the issue. Otherwise, please respect that we've made a decision here even if it's different than the one that you would have made. Thanks.

This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group