Provide time only representation, e.g. LocalTime

Hey,

Currently there is support for LocalDateTime, but I would like to use some time representation without a date. Ideall would be something like LocalTime for my use case.

my use case: represent daily events

my current workaround: use DateTimePeriod with a max of 24h in total

[bishiboosh]

I made a PR, @kluever @dkhalanskyjb could you maybe review it ?

[dkhalanskyjb]

introduction of time zones that need to be defined by restaurant owner of inferred from restaurant address/position

Does not seem all that terrible. For any fixed-offset time zones, the proposed solution works the same as the one you provided, so having a default of TimeZone.UTC or something in the same vein would mean that only the owners who don’t mind manually setting their time zones would be affected.

filtering of possible duplicities when time is shifted back as those do not make sense for the customer

I would argue that the duplicities should, in fact, not be filtered. If the time shift occurred outside of working hours, it won’t be reflected in the schedule anyway, but if it occurred during the workday, then some time slots would have an ambiguous meaning. So, a user who made a reservation at 13:00 on a day when 13:00 occurs twice wouldn’t know when the reservation actually begins and so would have to call the restaurant or do something else like that. If, however, duplicate entries were present, the user could conceivably remember (or be reminded by some text in the app) that there is a DST transition; then they would explicitly be making a reservation at the first time it’s 13:00.

The bottom line is that it looks like the domain you’re modelling does require handling time zone transitions, you just simplified this for the sake of ease of use in exchange for robustness. This may be a perfectly valid tradeoff in your case, but, from the library design perspective, the choice to ignore transitions must be done explicitly and with the full understanding of the consequences, so it seems for now that the (problematic in many cases) LocalTime arithmetic should not be very easily available.

Thanks for the elaboration, this does help a lot!