These are notes to myself, inspired by/based on Shan Rauf's How to Think About Time in Programming. All errors mine.
A time zone z is a tuple consisting of
A set Sz of time-formatted strings (in the intuitive sense). We never work with strings as such, but rather with time-formatted strings sz belonging to some specific time zone z. We'll take as understood the intuitive operations and comparisons within one of these sets ("one day after," "the earliest of these two dates," etc) in their naive interpretations over the strings.
A local absolute time function tz: Sz → R going from time-formatted strings to physical time (in the intuitive sense) in some relevant unit. Note: This function need not be linear or continuous with respect to the intuitive operations on Sz. This function need not be injective or defined over its full domain. Crucially, this function might be redefined arbitrarily at arbitrary points in the future (in the programmer time sense of future).
A normalization function uz: Sz → SUTC from time-formatted strings in z to one specific reference time zone UTC. This function need not be linear, continuous, injective, or defined on its whole domain, and might be redefined at any time in the future.
On this solid foundation we build the basic concept of the interval between two times, or rather, between two time-formatted strings xz and yz'. The most natural definition is the physical time interval, which in our notation is defined as tUTC(uz'(yz')) - tUTC(uz(xz)). Be advised that this isn't linear, continuous, or necessarily defined on either argument, and its value might change at any time in the future. Due to this last bit of fun, given two time-formatted strings you need to distinguish between the interval between them as an object/concept/spec, and the concrete number in minutes or seconds resulting from evaluating that interval with the functions involved as defined at that moment.
An alternative definition of interval — which often is what users are assuming in one way or another — is the local time interval between two time-formatted strings in the same time zone, i.e. tz(yz) - tz(xz). This, again, isn't necessarily linear, continuous, or necessarily defined on either argument, and its value might change at any time in the future, meaning that it's also important to be aware of the difference between the interval as object/concept/spec and its value when evaluated. It might, but need not, be the same as the physical time interval between the two time-formatted strings.
Finally, we can build comparison operators time-formatted strings — i.e., whether one of them is earlier than another — by looking at the sign of the interval between them. Meaning, of course, that the relative ordering (or even identity) between two time-formatted strings need not be defined or continuous (in the intuitive sense), might differ between local time and absolute physical time, and might vary over time.
Hope this clarifies things!
(Originally posed on my blog.)