is
Jon Skeet
NodaTime, should we use LocalDateTime for booking times?
We develop and maintain a booking system which has been used in Denmark for quite some years.
However we are now expanding our reach to countries outside one timezone and some customers will have a system that spans multiple timezones. So our naive DateTime approach will must likely give us problems in the future. I love the NodaTime approach which uses a specific class for a specific purpose this should make the learning curve easier for our devs.
However one of the things we save is the arrival time for a specific booking in a specific restaurant. For me this sounds for as a case where i would use LocalDateTime, this ensures that even a manager sitting at a computer with a different timezone would still see the correct arrival time (the time relative to the Restaurant's TimeZone, without us having to consider timezones) because no timezone is used.
If at some point we would like to display these times in different timezones local to the user (which for me doesnt make sense at the moment), we could do this by using the TimeZone for the restaurant and then calculate the relative time.
Would the correct class to use be a LocalDateTime, saved as a datetime in the SQLServer?
Are there any arguments that should have us consider ZonedDateTime for such a usecase?
If you always know the time zone associated with the local date/time of the booking, that's mostly fine. Presumably the time zone is associated with the restaurant of the booking.
The one problem you could run into is that a LocalDateTime and DateTimeZone pair don't always unambiguously determine an instant in time. If your restaurants are open late into the night and you go from summer time to winter time at 2am (becoming 1am) for example, then a booking at 1.15am could actually be for later than a booking at 1.45am. That's why ZonedDateTime contains a LocalDateTime, a DateTimeZone reference, and an Offset to resolve ambiguity.
Additionally, using just LocalDateTime may make it trickier to perform some queries - if you ever want to put bookings in their actual order of occurrence, you'd need to resolve them to ZonedDateTime values. But maybe you don't need those queries anyway.
Fundamentally, you should be able to provide a LocalDateTime and a DateTimeZone for any booking - and consider how to resolve ambiguity (or skipped times, going from winter time to summer time). If you've got that information/policy, that's fine.
See more on this question at Stackoverflow