hdinf (human-duration in format) parses duration information from human-readable format into an arbitrary format.
The frustration of seeing code littered with 86_400 and 60 * 60 * 24 and similar expressions.
import {
getDuration,
type HumanDuration,
type IntervalName,
} from 'hdinf';
// parseDuration(duration: HumanDuration, interval: IntervalName): number
getDuration('1 day', 'seconds');
getDuration('1 day 2 hours 3 seconds', 'milliseconds');In the wild, you should use this library remove any hard-coded durations from your codebase, e.g.,
- setTimeout(() => {}, 86_400);
+ setTimeout(() => {}, getDuration('1 day', 'seconds'));Similarly, anywhere where you define inputs for a function, you should consider using HumanDuration instead of a raw number in an arbitrary format, e.g.,
- const foo = (durationInSeconds: number) => {}
+ const foo = (duration: HumanDuration) => {}This will reduce the number of bugs that are introduced by passing in a duration in the wrong format.
One of the benefits of this library is that the input format is enforced using TypeScript template literal types, i.e. the compiler will complain if you pass in an invalid duration.
import { getDuration } from 'hdinf';
getDuration('1 day', 'seconds'); // OK
getDuration('1 day', 'milliseconds'); // OK
getDuration('1 day', 'minutes'); // OK
getDuration('1 day', 'hours'); // OK
getDuration('1 foo', 'seconds'); // TS error because foo is not a valid time period
getDuration('1 hour 1 day', 'seconds'); // TS error because lesser units cannot precede greater units (hour < day)Abbreviations are intentionally not supported. The goal of this library is to reduce the variations in how durations are expressed.
hdinf was primarily designed with the intent of replacing the use of constants rather than allowing dynamic expressions.
If you are already using a library like dayjs, you can probably find a native solution for this problem, e.g.,
import dayjs from 'dayjs';
import duration from 'dayjs/plugin/duration';
dayjs.extend(duration);
dayjs.duration(100, 'days');