Solutions and History of Timekeeping

Handling dates and timestamps is a very common, almost basic necessity in any program or application. It might seem to be something basic and uninteresting, but from my passion for history and through my experiences in designing IT solutions for the Travel and Transportation industry, I found it a non-trivial topic and an extremely good example of why re-using libraries and learning from past experience is extremely important.

History of Calendars

Wandering in Rome I found, close to each other and a few meters from the main Railways station, a couple of historical landmarks in the history timekeeping.  

In the first one, Palazzo Massimo museum, fragments of the roman calendars can be seen. The most famous of these is the one from Julius Ceasar, dating back to 46 BC. This calendar, the Julian Calendar, was a huge landmark in timekeeping, solving for the first time a consistent way the problem of handling the correct length of the year, through the introduction of the leap year (with February the 29th) every four years.

But even this was not enough, and timekeeping errors (even if at a much smaller scale) kept adding up for centuries. Since these errors endangered the calculation of the Easter date, finally in 1582 Pope Gregory XIII introduced the new Gregorian Calendar, which updated the rules for determining leap years (shortly, years divisible by 100 are not leap years, except if divisible by 400... getting more complex ).

So here's the second landmark, a great sundial used to develop this new Calendar and to compute the Easter date, in the church of Santa Maria degli Angeli.

Calendar libraries in programming languages

Any programmer with a bit of experience in the Java programming language has probably used the java.util.GregorianCalendar class, a modern implementation of a 16th-century calendar.  Other than this class, other libraries exist in Java, such as the Java 8 time API or Joda-time API, and the same is true for many other programming languages. Standard data formats such as ISO 8601 are so important as the basis for standardizing data exchange across APIs and REST services.

Timekeeping in the modern world needs to handle many additional concerns, such as Timezone, Daylight saving times, and also leap seconds (needed for adjusting Gregorian Calendar for real-time applications).

But still, to some programmers, handling dates seems to be a simple task that can be solved with ad-hoc custom solutions. Unfortunately, this often is not true and I have seen a lot of errors found only with an extensive testing DevOps approach.

So, unless special situations/requirements ask for it, it's always best to rely on a good library implementation. In my opinion, the maturity and ease of use of time libraries are some of the key evaluations aspects of new programming languages.

Solutioning a Clock architecture

But sometimes creativity can help in designing clever architectures for timekeeping. I am fascinated by the Swiss railway clock, designed in 1944 by Hans Hilfiker, and as an IT architect, I really focus on the algorithms and requirements vs the user interface.

The clock solved the problem of synchronizing the time across all Swiss stations through the use of a telephone impulse that every minute triggered the motor of each clock to advance the minutes hand at the same time all around the country.  What an amazing use of events and messaging for synchronization, a cloud-like solution from the 1940s.

But there's more: a second motor running locally, handles the seconds hand, with a full rotation in 58 seconds, and then stop at the 12 o'clock position, locked by a peg that unlocks at the minute event. So this is also an example of an edge solution, with local logic interoperating with network events.