WIP: Added Year, YearMonth and ArbitraryPrecisionDate

[wkornewald]

This is just a very quick example of how we could add support for an ArbitraryPrecisionDate that can be a Year or YearMonth or LocalDate or LocalDateTime or (later) ZonedDateTime (which could itself be a sealed class of OffsetDateTime and RegionDateTime).

The ArbitraryPrecisionDate could provide a parse() method that returns any of those classes (all of which implement ArbitraryPrecisionDate). At least in the medical space it's pretty common to have flexible date precisions in the official specifications, so you have to support at least these operations

• parsing
• machine-formatting back to the same precision string (so parsing results in the same object)
• human-formatting (displaying in the UI)
• sorting
• comparing

You might also want to treat the data differently based on its type. Here it helps a lot to have a sealed interface, so you can easily match all possible cases (which is also useful for the formatting and sorting etc. functions).

We could additionally have sealed interfaces for higher level subsets, so you can, for example, parse and work with any static type that contains at least a year-month-day.

What do you think?

[dkhalanskyjb]

I don't see why this is a pull request, given how sparse the code is. Could you instead file it as an issue?

Some notes in the meantime:

• Almost everything that you listed as the use cases has to do with parsing/formatting, and there are ways to do it, covering the use cases you listed, without introducing these classes.
• Sorting and comparing (isn't that the same?) are not related to parsing and formatting, but are they really needed? When is it useful to sort a list of 2020, July 2020, and July 27th, 2020? What should be the result and why? Seems rather fuzzy and arbitrary either way.
• Does "working with arbitrary things that contain a year-month-day" really require additional interfaces? If something contains a year-month-day, then LocalDate can be extracted from it and operated on. There are various *By operations for this in Kotlin, like sortBy.
• Making these things into a sealed hierarchy would mean that every case would have to be handled, but what if someone knows (and wants to represent in the type system) that, say, something has at least a month? In this case, they would have to re-implement this hierarchy, wrapping our classes. Now, the question: is there anything inherent in the Year-YearMonth-LocalDate(-?-?-?-LocalDateTime?) hierarchy that makes it somehow the best one? Are the use cases for precisely this hierarchy overwhelmingly more common?

[wkornewald]

I don't see why this is a pull request, given how sparse the code is. Could you instead file it as an issue?

I just wanted to develop iteratively with some actual code instead of sending around code snippets.

Some notes in the meantime:

* Almost everything that you listed as the use cases has to do with parsing/formatting, and there are ways to do it, covering the use cases you listed, without introducing these classes.

Sure. A sealed hierarchy would just make it a little bit easier to prevent mistakes. Otherwise you can just wrap everything with a custom sealed hierarchy and introduce formatting, serialization, sorting at that level.

* Sorting and comparing (isn't that the same?) are not related to parsing and formatting, but are they really needed? When is it useful to sort a list of `2020`, `July 2020`, and `July 27th, 2020`? What should be the result and why? Seems rather fuzzy and arbitrary either way.

It's useful when you have mixed data. 2020 is before July 2020 which is before July 27th, 2020. I think that's still intuitive behavior from an end-user perspective.

* Does "working with arbitrary things that contain a year-month-day" really require additional interfaces? If something contains a year-month-day, then `LocalDate` can be extracted from it and operated on. There are various `*By` operations for this in Kotlin, like `sortBy`.

I think it can be useful when implementing a function that can work on such arbitrary things or that wants to use static typing to set a minimum requirement. E.g. you might want to store a full date or a year-month to allow calculating something in a sufficiently meaningful way, but still allow the user some fuzzyness if an event can't exactly be determined/remembered.

* Making these things into a sealed hierarchy would mean that every case would have to be handled, but what if someone knows (and wants to represent in the type system) that, say, something has at least a month? In this case, they would have to re-implement this hierarchy, wrapping our classes. Now, the question: is there anything inherent in the `Year`-`YearMonth`-`LocalDate`(-`?`-`?`-`?`-`LocalDateTime`?) hierarchy that makes it somehow the best one? Are the use cases for _precisely this_ hierarchy overwhelmingly more common?

The Year / YearMonth / ... hierarchy is a strict ordering from less to more precise time information, it's how medical specs work and I think humans also find this the most useful way. If you had a vaccination in 2016 you can at least say whether you need a booster. If you only know it was in July but don't know the year then there's not much you can usefully do with that information.

At least, this hierarchy has real-world use for us and it would be more comfortable to work with if it was implemented within this library instead of us having to wrap everything.

[dkhalanskyjb]

I just wanted to develop iteratively with some actual code instead of sending around code snippets.

Still, I think this should be discussed in the issues section. The discussion section for the pull requests is for discussing the code, not the issues. Other people facing the same problem may well decide not to write anything if they see that a pull request for this already exists, thinking that there's some finality already.

In any case, there's not much code to discuss, we would just be discussing the issues.

[wkornewald]

I'll open an issue later (hopefully today).

[wkornewald]

See #177