Unit conversion functions

[ctf0]

is it possible to have like a helper function that can convert a date to another ?

ex.

convert(2, 'hrs', 'milli')
convert(1, 'month', 'hrs')
etc...

[edorivai]

What is it exactly that you want to accomplish? In case you want to convert durations, this can be done with math!

// 2 hours in milliseconds
2 * 60 * 60 * 1000; // 7200000

// 1 month in hours (approximately, because it depends on your definition of the length of a month)
const averageDaysInMonth = 365.25 / 12;
1 * averageDaysInMonth * 24; // 730.5

[ctf0]

exactly that but for ppl that suck in math like myself, the helper will be the perfect answer

[kossnocorp]

This is a good idea, however, I don't like the proposed API. I suggest making it explicit, like secondsToMinutes(45), hoursToDays(123), etc.

PRs are welcome.

[edorivai]

Oh my, should this be a cross map of all different time units? Also, we should probably make a table of definitions. Like how many days is a month? A year? Do we do gap years?

[Lakston]

I can try do do something for this request but we would have to define the API and what conversions we would plan to support because some can get a bit tricky as mentioned by @edorivai , if you want to convert minutes to months, would you take the current month length ? allow for a month argument (that would not fit with a simple, explicit API) ?

The easiest ones to start with would be :

• seconds => minutes
• seconds => hours
• seconds => days
• minutes => seconds
• minutes => hours
• minutes => days
• hours => seconds
• hours => minutes
• hours => days

When getting into months / years territory it gets more complicated with months duration and gap years. And with an explicit API that's already 9 helpers.

Maybe an optional argument such as minutesToYears(15962, true) where true defines if the year is a gap year or not and secondsToMonths(15472, 30) where 30 would be an optional month duration.

(even then I already see a problem with my proposal, what if the number of seconds is equal to more than a month, you wouldn't want to get the number of 28 days months since they do not exist in succession, same for gap years, so going for the average days in a month would be better)

Additionally, I like the fact that the function names in date-fns can be 'grouped' by their prefixes (add, isSame, lastDay), it makes learning the API a lot easier so having a consistent naming for helper would be better in my opinion.

Maybe convertXtoY ?

[ctf0]

imho using the explicit api will be hard to maintain while using the one from the main topic is easier as it can be done using switches.

on -a-side-note apparently this is hard to create because of the indifferences in month days & year months

[leshakoss]

For the record, without any ambiguity it is possible to convert between these groups of units:

• milliseconds ↔ seconds ↔ minutes ↔ hours
• days ↔ weeks
• months ↔ quarters ↔ years

[edorivai]

@leshakoss hours ↔️ days?

[leshakoss]

@edorivai some days are 23 or 25 hours because of DST

[edorivai]

Damn, you're right

[kossnocorp]

@ctf0

imho using the explicit api will be hard to maintain while using the one from the main topic is easier as it can be done using switches.

I can't see how switches could be easier to maintain than dedicated functions.

on -a-side-note apparently this is hard to create because of the indifferences in month days & year months

This is yet another reason why the API should be explicit. If we'd allow converting anything to anything it would result in issues that are hard to debug.

Besides that, implicit API would be inconsistent with the rest of the library.

---

As @leshakoss noted, we're looking for explicit API that allows converting only compatible units:

• milliseconds ↔ seconds ↔ minutes ↔ hours
• days ↔ weeks
• months ↔ quarters ↔ years

I like the unitToUnit naming scheme, i.e. daysToWeeks(12) cc @Lakston

Another question is what should we return floats or integers. @leshakoss WDYT?

[edorivai]

@kossnocorp If we say we only want to convert compatible units, is it then really worth it to increase the API surface? I mean, the compatible conversions are arguably trivial to do by hand.

I could see the use in date-fns actually defining "sensible defaults" for the problematic conversions, but then again, maybe in this case there is no such thing as sensible defaults.

If I would personally have to make the call I would probably say it's not worth the extra API surface. But if enough people think it's worth it, then be my guest and add it.

[ctf0]

@kossnocorp what i meant by a switch is to have a fluent method, like for example
u search google on how to convert 1gb to mb, but now we also want to know what is 1gb in kb, so instead of re-searching u just select the new type you want to convert to.

so in our case we write one method & simply change the types to whatever we want without having to memorize/search all the api methods to convert from one thing to another.

so how this might work is you get the 2 params and find the gap between them ex

convert(2, 'hrs', 'milli')
// milli > min > hr
// get millis in a min = 1000 x 60
// then mins in hr = 1000 x 60 x 60
// then get the main count = 2 x 1000 x 60 x 60

convert(2, 'month', 'hrs')`
// hr > day > month
// get hrs in a day = 24
// then days in month = 24 x 30
// then get the main count = 2 x 24 x 30

[Lakston]

If I would personally have to make the call I would probably say it's not worth the extra API surface.

I would agree with that, expanding the API with functions that could be done that easily doesn't sound great.

I proposed my help because I was waiting for the issues about the localisations updates to be created (I started working on updating the 'fr' locale to match the latest release but had some questions so I was looking for an issue to tackle in the mean time)

[kakadiadarpan]

If anyone is still looking for a utility like this, check this out: https://github.com/zeit/ms

[jatin33]

Can I work on this issue?

[leshakoss]

@jatin33 sure! Thanks a lot!

[fturmel]

@tan75 I think this issue can be closed since #2433 was merged.