date: period: P7D is normalised to P1W even when normalisation is not set

Fair point. It’s an easy enough change and probably won’t affect people adversely because both forms are equivalent.

NewWithWeeks which is, well, explicitly describing differents

What about instead doing:

func New(year int, month time.Month, day int) Date
func NewW(w int) Period

Drop NewYMWD and New2 as they are initializers for an illegal format.

type PeriodOfWeeks int
func (p PeriodOfWeeks) Date() Date

PS! As far as we are concerned (me and @khtufteland), the only purpose of this issue is to prevent automatic normalization into weeks. Direct week support is not something we care about. We have switched to our own implementation now that fits our exact needs though.

As for everyone else proper direct week support would probably only allow weeks to be non-zero if you have zero date type and zero time components. E.g. imagine:

type Period{
   // Allow either date or weeks
   date Date
   weeks int16
   // Time component only allowed when weeks is 0.
   hours, minutes, seconds int16
}

@rickb777 want to ask, why all values in Period time multiplied by 10? Looks pretty strange honestly

I agree this looks very strange. Perhaps to support sub-second precision without a nsec parameter @rickb777?

---

Of topic, but have to mention it. IsPositive appear to ignore the case where the period IsZero. Would it not be easier to return !p.IsNegative()? Then it should also cover the IsZero case.

@rickb777 oh, you’re alive! That’s a good sign 😆