Applies to: A viewer converts a month-based label into a fixed number of days without applicable source terms.
The useful distinctions
- Calendar months have different lengths.
- A month-based convention needs its own boundary rule.
- A generic time example does not establish subscription or renewal conditions.
Do not insert a boundary rule that was never supplied
A label containing the word “month” can describe a calendar-based convention, while a stated number of days describes a different kind of interval. Do not assume they are interchangeable. Record the wording and ask how the source defines the start, end and any month-end handling. This is a clarification task, not a reason to invent a billing, trial or renewal policy from a general calendar example.
Separate a calculation from the applicable terms
A calculator can produce a date for a chosen rule, but it cannot prove that the rule is the one the source intends. Keep those layers separate. If a commercial period is involved, use the approved account-specific conditions and full term label rather than a guessed day count. If the source has not supplied exact boundaries, preserve that uncertainty instead of presenting a neat-looking result as a confirmed activation or expiry promise.
Hypothetical worked example
A fictional planning note says “one calendar month from 31 January”, but does not explain its month-end convention. Another note says “thirty days”. The two phrases need not identify the same end boundary. The viewer asks the note’s author for the intended rule rather than forcing both into one date. This example does not establish how any StarShare plan handles activation, expiry, billing or renewal.
A focused way to proceed
- Keep the source’s exact period wording.
- Ask for its confirmed start and end boundaries where they matter.
- Avoid replacing a month label with an assumed number of days.
When to stop or ask for help
Request the applicable period definition and confirmed boundaries rather than substituting a universal day count.