make NaiveTime::MIN public

[esheppa]

This will be useful in NaiveDateTime::new and NaiveDate::and_time in reducing the amount of times that users have to use the fallible APIs.

This could potentially be extended with:

• More consts, eg NaiveTime::H1 thru NaiveTime::H23
• An infallible NaiveTime constructor that takes an enum Hour and enum Minute potentially enum Second.

[esheppa]

Before we merge this, if you like NaiveTime::H1 thru NaiveTime::H23 then I could rename MIN to H0

[djc]

IMO having 24 constants is a bit too ugly for my taste, I'd rather figure out a way to do get some const stuff working.

[esheppa]

Yep fair call, lets merge this then, and I'll do a seperate PR with an enum Hours { H0..H23 } or an alternative like NaiveTime::<H, M, S>::new(). Importantly the enum hours isn't as nice, but works on 0.4.x, whereas the latter only works on very recent rust (needs const-panic)

[djc]

I think the enum would also be too ugly. I don't think we should go overboard on making everything infallible, it should be fine for API users to call .unwrap() if they are statically convinced the inputs are fine.

[esheppa]

I think the enum would also be too ugly.

Makes sense.

it should be fine for API users to call .unwrap()

In general this is good, however there are two specific cases where this isn't ideal:

• In const contexts (unwrap is not yet stable there so if let or match must be used instead)
• When compiling for embedded or wasm in the browser, small code size is important and each call to unwrap adds more format strings to the code (which is the reason for https://docs.rs/wasm-bindgen/latest/wasm_bindgen/trait.UnwrapThrowExt.html)

Hopefully we can find an ergonomic-enough solution for those, which could well be const fn new<const H: u8, const M: u8, const S: u8>() on NaiveTime

[djc]

Yeah, at this point I think we should just start an opt-in const API for which we can require a modern MSRV.