Export helper functions from datetime package

[rneogy]

Environment

• Package version(s): @blueprintjs/datetime@4.3.1
• Browser and OS versions: Any

Feature request

It would be helpful if all the helper functions in the datetime package were exported by the package.

One great feature about Blueprint is its composition of smaller, more-specific components into larger, more general ones, so that if users want to customize components, they can use the smaller components instead of the larger ones. I've found myself in this scenario, where I wish to customize a lot of the more generic components provided by Blueprint. In particular, I wish to create my own DateInput and DateRangeInput, but I'd like to build off the existing source code as much as possible. However, the source code uses a lot of non-exported helper methods, such as getFormattedDateString from dateFormat, or others from datePickerCore. You can see this usage here and here.

Some of these are already exported, such as the DateUtils. It would be nice if the rest were exported as well.

Examples

n/a

[adidahiya]

Makes sense. I had a similar need to use some private helper functions in the new datetime2 package I've been working on. I actually have a PR open where I'm exporting getFormattedDateString from datetime as public API: https://github.com/palantir/blueprint/pull/5390/files#diff-eba6e954fcf32ebfd9d7ba9df926e77ca81c1c54ec2eef9c13b133169ace0a6fR24-R28

I don't want to export everything as public API, however -- I prefer to be more conservative about what gets added to the API, since otherwise it becomes hard to break things and delete code. Please let me know which additional functions you need exported, and I'll consider exporting them.

[rneogy]

It looks like you've basically addressed most of my use-case in that PR. The main things I needed were getFormattedDateString, getDefaultMinDate, and getDefaultMaxDate. The only other thing that would be nice to have would be IDatePickerBaseProps, as it's used in the implementations of DateInput and DateRangeInput. I actually see you renamed it to DatePickerBaseProps in the PR, which makes sense. I get your point about not exposing too many things in the API so that these changes can be easily made. Do you think it's fair to expose DatePickerBaseProps?

[rneogy]

Unrelated, I'm very appreciative of the work you're doing maintaining this library and upgrading the datetime package! Excited to see how it progresses :)