Yeah, timestamps should always be stored in UTC, but actual planning of anything needs to be conscious of local time zones, including daylight savings. Coming up with a description of when a place is open in local time might be simple when described in local time but clunkier in UTC when accounting for daylight savings, local holidays, etc.
An Instant represents single point on the universal time line. This can always be converted to LocalTime and vice versa. For periodic jobs, you calculate the next occurrence in the local time and then save it as an Instance (UTC).
Doesn’t always work, especially if you need to work with any sort of calendar or recurring schedule.
Yeah, timestamps should always be stored in UTC, but actual planning of anything needs to be conscious of local time zones, including daylight savings. Coming up with a description of when a place is open in local time might be simple when described in local time but clunkier in UTC when accounting for daylight savings, local holidays, etc.
An Instant represents single point on the universal time line. This can always be converted to LocalTime and vice versa. For periodic jobs, you calculate the next occurrence in the local time and then save it as an Instance (UTC).