The correct way to model a timestamp range is [start, end)
Or things that are not mathematically precise will cause you pain down the line.
I've encountered timestamp ranges often in my professional life at Stripe and anywhere else. Every time a timestamp range isn't modelled correctly, it causes pains and sufferings.
The correct way to model a timestamp range, using the mathematics interval notation, is: [start, end).
In a natural language, this means the range spans from start up until end, but end isn't included in the range. This modelling approach precisely covers the last second, millisecond, nanosecond, and <whatever-smaller-unit-of-time>-second.
A suboptimal approach that I've seen a lot is to use inclusive end i.e [start, end]. This will cause great pains. It would be tricky to change the smallest unit of time (e.g. from second to millis). Any further calculation would need to know both the range and the smallest unit of time. For example, calculating the length of a range would require +1 <smallest-unit-of-time>. Checking whether an exact timestamp falls onto the range would require a special handling on the last unit, which would require knowing the smallest unit of time.
Stepping back, why would any other approach be problematic? The answer is because they don't represent the reality in a precise and elegant manner. They would require you to carry an additional info, the smallest unit of time, in order to be precise.
When we say: the subscription is from the first of the month until the end of the month, that range would include the last second of the month, the last millis second, the last nanosecond, the last attosecond, and the last <insert smaller unit of time>. [start, end) captures this reality without needing further information.
Bonus point: we should always use UTC. Because local timezones might not be uniformly continuous. For example, it might be impacted by daylight savings, which makes some points in time invalid and some other points ambiguous. Local timezones are also impacted by politics and can be arbitrarily modified by local governments (read more: Edgecases for timezones).