Leap Seconds. Will our Understanding of Time Change in 2015?

No matter what programming language we choose, we programmers all share one big misery: Having to deal with calendars. We all get it wrong dozens of times in our working lives. And when we think we finally understood calenders, we get taught better. While some take the time to delve into the misteries of calendars, others are faced with this situation:

Found here: http://de.reddit.com/r/funny/comments/1dxec2/at_some_point_all_programmers_will_experience_this/

Google “programming” and “calendars”, and you’ll find lots of interesting discussions, such as:

In 2015, things might change (again). Here’s an interesting article about what would happen if we stopped coupling our calendars to our earth, moon, and sun – a programmer’s dream! Enjoy…

4 thoughts on “Leap Seconds. Will our Understanding of Time Change in 2015?

  1. A big part of the problem is not having libraries which properly handle calendars. I understand calendars, but have yet to use a common library, for any language, which actually implements them correctly. There’s inevitably bits always missing: UTC formatting/parsing, timezone conversion, time deltas, etc.

  2. Some years ago a new business mobile phone was introduced in Hungary. It had calendar synchronization with Outlook. In the phone setup there was no Budapest time zone, but there were many different GMT+1 (sic) time zones so we decided that the closest capital to Budapest in the list was Belgrade.

    Sometime in spring a lot of service calls came: the meetings were one hour off on the phone as on Outlook desktop application. We invested man days if not weeks to investigate the problem to no avail. After two weeks the problem disappeared. We faced the same nightmare during fall.

    It was the next year only when we realized that the time zone change from summer time to winter and the other way around was not performed the same day in Serbia as in Hungary. The solution was to use the time zone named Berlin in the configuration of the phone.

    The next summer/winter time change was already having a version of the firmware that included Budapest with its “own” time zone.

    1. Hah, thanks for sharing! Yeah, that sounds familiar! :-)

      I was once looking for missing banking transactions in a report, of an ominous October 31, 2004. They were missing only on that day. Only in that year. Not on a subsequent month, not in any other year. It struck me like lightning that:

      • October 31, 2004 was a Sunday
      • It was when CEST shifts to CET
      • It was the end of the month
      • The SQL predicate range to include monthly transactions went from the first of the month until the TRUNC(last of the month + 24h)

      Duh. October 31, 2004 had 25h which made the filter exclude the entire day. Only on that day. Only in that year. Not in any other year (when the shift from CEST to CET was earlier in Switzerland). And it was a Sunday, so only few banking transactions were generated, so it took a long time to be noticed…

Leave a Reply