The time! The time! Who’s got the time?

Home » Blog » Software » The time! The time! Who’s got the time?

I’m currently working on an app that allows you to set and display dates and times in various ways. Hence, lately I’ve been working quite a bit with calendars, dates, times, date localization and all the funny intricacies that come with them.

To name but a few of those:

  • In some countries the week customarily starts with Sunday, while in others it starts with Monday.
  • Some programming languages and date APIs use 0 as the index for the first day of the week, some use 1. Combine that with the previous point and you’re in for a lot of fun, especially if you want date-related user interfaces to be correct and consistent across several locales.
  • Which brings us to: Time zones! There are about 40 of them (on Earth, that is …). They’re defined by their offset from UTC – also known as Greenwich Mean Time (GMT) – and one might expect them to be an hour apart from each other because that would be somehow logical and simple. However, only most of the times they’re an hour apart, sometimes it’s half an hour, sometimes 45 minutes. This is mostly due to geopolitical issues. Quite understandably smaller countries wouldn’t want to be divided by time zones, which is also why those time zones are by no means fixed but change every year or so. Add daylight saving time to that for additional hilarity …
  • A fun aspect of calendars is wrap-around at the beginning or end of each month or year. To which month or year does a week belong that spans two months or years? Is the last week of a year calendar week no. 53 of the current year or calendar week no. 1 of the next year? Yes, there are definite answers to those questions but they cause problems with calendar displays nonetheless. Don’t even get me started on leap years …
  • Date APIs in programming languages are notoriously convoluted. Fortunately, I haven’t used Java for this app because – well – Java’s date API in its current incarnation simply is completely fucked up. The Ruby date API is much better but it still has a lot of quirkiness to it: There are Date, Time and DateTime classes, which all kind of do the same thing but each from a slightly different perspective.
  • I haven’t even touched on the subject of calendar concepts that are quite different from our usual Western world calendars such as the Chinese calendar or the Hebrew calendar.

This actually makes me wonder how we’ve arrived today without losing a year or two here and there during the course of history …

These numerous problems and special cases explain quite well why humans have spent considerable time on designing and establishing simple and consistent calendar systems, sometimes successfully, sometimes less so. It also accounts for the fact that we still remember the people who invented or introduced them as namesakes of those calendar systems.

Accurately keeping track of time is a considerable achievement of mankind that most of the time we simply take for granted.

Still the question remains why further simplification of calendar designs seems to be such an enormous problem. Some attempts at that have been made in the past, for instance the French Republican Calendar and Swatch Internet Time, both of which have failed.

The former is also a nice example of why – in my opinion at least – calendar designs only change slowly, if at all: Time can be used for exerting political power. Sure, the French revolutionaries also wanted to simplify the calendar but first and foremost they wanted to convey a political message, which in this case was the removal of religious and royalist influences. Similar tendencies can still be seen today with daylight saving time: It’s still widely used though for no good reason other than showing that nation states have the power to define the time by which their citizens live.

Anyway, so far about date, time and calendars. No time to say “Hello, Goodbye”. I’m late, I’m late, I’m late.

Coming up next week: Another complex yet often underestimated problem in software development: I18n

  1. Pingback: i18n is a hard and largely unsolved problem | Björn Wilmsmann

Leave a Comment

By continuing to use the site you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or if you click "Accept" below then you are consenting to this.