Add LocalDate.{Min,Max}Value

[roji]

Much like #356 but for LocalDate.

[jskeet]

SGTM - do you think it's reasonable to throw an exception if they use different calendar systems, just like CompareTo does?

I think it would be reasonable to get this in for 2.1 (currently in beta). Do you have anything else you'd like for Postgres support? (It could be a while before 2.2...)

[roji]

(I'm not yet very familiar with how calendar systems and LocalDate interact) If I understand you right, you're saying that {Min,Max}Values would be tied to a specific calendar system (because we can't talk about a system-independent maximum value) - that definitely makes sense. But which operation exactly would throw an exception and when? If I understand correctly CompareTo already does so?

Regardless, there's an Npgsql feature which relies on this, but I can't say it's extremely important. In case you're interested, PostgreSQL date and timestamp support special infinity and negative infinity values in the database, and Npgsql provides an option to convert {Max,Min}Value to these. I'm doing this for timestamp but ran into the lack of {Max,Min}Value for dates. This is definitely non-critical.

Otherwise there's nothing more at the moment that seems to be lacking for me - it's quite exciting to be able to provide NodaTime types for Npgsql via a plugin. I'll write a blog post about it soon.

[jskeet]

Ah, sorry, I'd not paid enough attention - I thought you meant methods of

LocalDate Max(LocalDate, LocalDate)
LocalDate Min(LocalDate, LocalDate)

Those sound useful as well :)

For MaxValue and MinValue properties... I think we could easily expose MaxIsoValue and MinIsoValue, which are tied to the ISO (Gregorian) calendar. I suspect that's all you need.

(And I agree that having support in Npgsql will be exciting. I look forward to the blog post!)

[roji]

MaxIsoValue and MinIsoValue would be perfect. For completeness it might be a good idea to have a way of obtaining max/min values for other calendar systems as well, but that's definitely not something I need myself.

Max/Min methods for pairs of dates also sound useful.

[jskeet]

Righto. Will try to do that this weekend.

[malcolmr]

I went looking to see if we ever had these (e.g. pre-1.0), but it looks like we didn't. I guess we didn't want to tie ourselves to the calendar system. (And I think our story about valid ranges was a bit muddled pre-2.0.)

Have something that's clearly ISO-only makes sense to me too.

(e.g. we already needed a MinIsoDate / MaxIsoDate in DateIntervalTest.cs; I'm assuming those would be the same values?)

[jskeet]

Yup. For other calendar systems, I think it makes sense to have MinDate and MaxDate properties on CalendarSystem. We have MaxYear and MinYear, so it's not much of a stretch from there. I think those can go post-2.1 though.

[malcolmr]

I do have a chat log with you mentioning in passing possible problems with static initialisation order in reference to a potential LocalDate.MinValue, though, but I don't have any other context.

Any idea whether that's a real concern?

(It was about whether we had a test that verified the class initialisation formed a DAG.)

[jskeet]

If we make it a property instead of a field, it should be fine.