ms
ms copied to clipboard
vercel
Add support for month/months and weeks
A month doesn't have a fixed duration, it can be 28, 29, 30 or 31 days..
But still when you ask google "how many days in a month" the answer is 30.4167 days
Google is doing 365 / 12 = 30.4167 days.
But because a (julian) year defined as 365.25 days (source: IAU.org) 365.25 / 12 = 30.4375 days is more appropriate.
Should we add month unit?
Pros: It's convenient and some of us need it Cons: A month doesn't have an official fixed length
@yvele thanks for describing it better.
Definitely agree on having it available. But it should say it is equivalent to 1/12 of an year and doesn't correspond to a specific month.
@yvele Nice work describing this issue, thanks!
I’d disagree about having it available, and would instead recommend '30d' or some larger multiple?
This is a hard one, because the convenience is nice and the expectation is there -- e.g.: "why do you support years but not months?", but I agree with @BurntCaramel.
Supporting months could easily violate the principle of least surprise for people who don't look at the source. ms("1 month") will never coincide with any calendar month. ms('30d') is explicit and keeps the module's purity and accuracy with no ambiguity.
Also, thanks to @leo for #55 -- I was midway into writing a PR when it occurred to me to check existing ones. =P
@EyePulp @BurntCaramel +1
Is it worth just putting a note in the readme that month can be achieved with 28 days or 4 weeks?
My 2 cents:
msis usually used for durations, not for dates, so I don't think it's a big issue that it does not correspond exactly to the current month length- even though it's clearly different from the variability in month duration, year is not an exact number of days but still supported, day is not an exact number of seconds but still supported
- IMHO the principle of least surprise would be for month to be recognized like year or day
- you don't like month, don't use it :slightly_smiling_face:
@julien-f It's true that both years and days have a fuzz-factor, but it's a smaller amount of change over a longer period of time, and there's widespread agreement on how to represent their "standard" duration (or else this library wouldn't exist).
However, months are weird, and expectations vary on what should happen when ms('1 month') is calculated.
Months have fixed variability in length (is that the right way to describe it?) per instance of each month. I think there's potential for surprise when hardcoding a fixed duration because everyone knows they are not fixed. I think documentation saying "we chose X days to represent the length of one month" is fine, but it essentially hobbles the month unit to a narrow use case and assumes a lot of agreement already exists around the concept of a month's duration.
Sorry, had to edit - I hit enter too quick. =)
I noticed that 1m and 1M have the same value when using "ms" which is 60000.
This is very confusing since I expect 1m to be one minute and 1M to be one month.
I suggest removing conversion of "M" units until there is support to express months.
At least, until you figure out whether or not to support months, would it be possible for ms to throw when receiving a number of months ?
Actually it just returns undefined, so there is a high risk of not noticing that a number of milliseconds wasn't returned and that the error has noticeable effects somewhere else, which can be hard to debug.
Considering that the expectation is very high that "1 month" is as available as "1 day", "1 year", or "1 hour", that would be much appreciated.
My vote is for 1 month to just be an alias 30 days. My use case is the user typing and running ms on their input. They can do 1 hour, 1 week, but when they try 1 month, nothing happens.
