When scheduling an appointment (event) in the future and you need to move it around, these fields are necessary. Repeating events are similar, as you already me

When scheduling an appointment (event) in the future and you need to move it around, these fields are necessary. Repeating events are similar, as you already mentioned. Millisecond precision is just the standard. I would say nanosecond should be the standard, but it isn't yet. The durations are very useful for basic arithmetic on time. An hour isn't always an 60 times 60 seconds (leap seconds) and a day isn't always 24 hours. So, if you have two buttons in your UI which move your appointment around, or which calculate the end-time of a one-hour appointment, you want to be able to use the type '1 hour', and not 60 times 60 times 1000 milliseconds. The partial dates are very common and miscalculations are often made. It is notoriously difficult to calculate with partial dates and warrants a type with associated methods/functions. I see myself often writing something like: `new LocalDate(5,5).toInterval().contains(now)` (where obviously, the localdate is automatically deserialized from JSON or sth alike).