Hacker News new | ask | show | jobs
by sesm 1043 days ago
Most of confusion can be resolved by introducing 3 separate entities (and naming them properly):

- Instant - a point in monotonously increasing time (Unix timestamp is usually a good enough approximation for most cases)

- Calendar

- Wallclock - non-monotonous human-readable clock

Being precise about which entity is used is enough to resolve most of the confusions.

For example, scheduling a doctor appointment is always Calender + Wallclock in a location of doctor's office. No Instant should be used to record this, and changing of DST rules for this location shouldn't affect the appointment. DST rules only matter if we want to convert from one Calendar and Wallclock to the other, then Instant may be used internally in calculations.

Back to the article: if we are talking about subscriptions, then we should specify, if subscription is valid for time interval of 365*24*60*60 seconds or the expiry is tied to Calendar+Wallclock, but in this case Calendar+Wallclock should have a specific location. The first option is much easier to implement, and to avoid any timezone/DST frustration adding an extra day of subscription (366 instead of 365) will be enough.

1 comments

I think in most systems, calendar is called LocalDate and Wallclock is either LocalTime or combined with a LocalDate into a LocalDateTime.