Expose MIN_TIME and MAX_TIME of NaiveTime

[rikvdkleij]

See #386 (comment)

[djc]

Hmm, would it make more sense to expose these as NaiveTime::{MIN, MAX} associated types? I think that would be more idiomatic in modern Rust, at the cost of some consistency with current constants. We could introduce DateTime::{MIN_UTC, MAX_UTC} to fix the consistency, deprecating the other constants. @esheppa thoughts?

[esheppa]

@djc - I think making them associated is a great idea. Given the two options, either associated constants on the trait or associated constants in the inherent impl, I'd lean toward the latter, among other reasons, people are likely to have the type names already imported, but potentially not the traits, so its more ergonomic to get at the constants if they are associated constants on the inherent impl. (This is the same IDE friendliness reasoning that was persuasive in #711)

[djc]

Okay, so let's do the associated consts (with the _UTC suffix in the case of types that take a TimeZone argument) and deprecate all the old MIN_ and MAX_ constants, with a note in the deprecation pointing to the new API.

@rikvdkleij does that seem like something you can tackle?

[rikvdkleij]

@rikvdkleij does that seem like something you can tackle?

@djc No, sorry, it was just my intention to get access to the MIN_TIME constant and make it consistent with the other constants.

[djc]

Fixed this with #726 instead.

[djc]

I guess that PR doesn't yet actually expose those values, so feel free to submit a new PR for that.