Hell of a time
Tomasz Kuczma
The hell of a time idiom has two opposite meanings - having a good or a bad time. I would rather to talk explicitly about the hell which is dealing with time and time zones in computer science.
The first impression is innocent
There is a Unix time which is just 32-bit integer incremented every second. 0 value means the date 00:00:00 Thursday, 1 January 1970 UTC. It is also called UNIX epoch time as we calculate time inside one epoch. We switch to the next epoch and start counting from 0 value again when this 32-bit integer overflow. Second is the SI unit which is well defined as “the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom.” Definition of the second given by the BIPM at the 13th General Conference on Weights and Measures in 1967 (at a temperature of 0 K to be exact). The above part is obvious. Things start to be a little more complicated when time zones come into play.
Imagine an app
Imagine a flight-tracking app that shows dates of departures and arrivals. A plane can take off in some country (in some time zone e.g. CEST - Polish time zone) and land in another country (in a different time zone e.g. BST - British time zone). A user wants to track the flight while physically being in yet another country (so in yet another time zone e.g. EEST - Finnish time zone). Flight takes some time of course (e.g. around 2:40h from Warsaw to London).
Sound easy. Looks like simple integer addition, doesn’t it? Nothing could be more wrong!
Just wait and let me remind you what is, for example, the Indian time zone. It is IST = UTC+5:30. See even “crazier” examples here
. That complicates things. Isn’t it? And another question is how to deal with daylight saving time or the international date line? If you work in one of the international companies you should notice that daylight saving time change happens during different days in different time zones. Also, remember that sometimes countries changed their time zones and other time-related regulations even multiple times in their history (e.g. Russia).
Things are even more complicated and I recommend you to watch belove video to understand how complicated the problem is https://www.youtube.com/watch?v=-5wpm-gesOY The most interesting part (for me) starts at 6:43 and 9:16 - it’s related to leap second problem.
Does it really happen in production?
Unfortunately, yes. I personally used many apps that had bugs due to different issues related to time calculation. Few of them are:
- Vocabulary learning app
I use an application that helps me learn English. It pushes notification with a new word to learn every day at the set time (e.g. 10 a.m.). But someday, the app just started pushing notifications an hour earlier.
I quickly correlated it with daylight saving time and awarded it with a smile :) Obviously, the developer did something like:
nextNoifictionTs = now() + 24*60*60*1000; - Reporting system I scheduled periodic summary reports in some old system I had to use. Reports were about the usage of specific system resource so it helped me track my cost and detected anomalies. I run the first report on 1st April and selected the option to repeat it “every 1 month”. The report came properly on 1st May but the next one came on 31st May… It was weird. When I emailed support they explained to me that in their system a month has always 30 days for simplification. Yey, isn’t it a perfect implementation of what programmers say “it’s not a bug it’s a feature”? Fortunately, February was already a past month but regret that I didn’t ask them how they call 5 missing days in their year definition (6 in leap year). I guess that those days are “maintenance days” or “unavailability days” (of course excluded from SLA).
- “Intelligent” light bulbs I use an intelligent light system which helps me wake up fresh and fall asleep smoothly. The system has many features but I simply use to use it just to brighten and darken the light bulbs to regulate the level of melatonin. Some time ago I moved from Poland to Ireland where I had to adjust timezone by one hour. I plugged in a control bridge and checked if everything is set up properly via a mobile app. It looked ok so I went to sleep really happy that things went smooth. However, in the morning light turned on an hour earlier and woke me up upset. I tried to check the time zone in which the device operates and fix it. I tried to allow device to use my location to adjust some settings but it didn’t work out. Finally, I found the proper option after an hour hidden somewhere in the darkness. I have to admit that it wasn’t technically a bug - just a weak UX. But on the other hand, other applications (like Google Calendar) can handle that somehow and ask a user instead if he wants to use a new time zone or the old one.
Is this only a software problem? Does it affect other businesses?
Is there any business that can run without software nowadays? There are probably not many of them but still, I’m able to find an interesting example of “time manipulation” which affects day to day operations. Last Sunday (27th October 2019 at 3 a.m. CEST) 17 trains of PKP Intercity (one of the polish national rail carriers) stop for an hour due to daylight saving time (official statement ) because 3 a.m. CEST changed to 2 a.m. CET. I’m not sure why they do it - maybe for some safety reasons or it is just a “past times mindset”. The question is what do they do in the opposite shift from CET to CEST when clocks are turned forward 1 hour? Teleport trains?
Should we stop using daylight saving time?
Russia stopped observing daylight saving time in 2011 due to many problems e.g. cow milking in the farming industry - [more stuff here](https://www.theguardian.com/news/2019/oct/21/spring-forward-fall-back-who-changes-the-clocks-when-and-why Fortunately), the European Parlament voted to deal with this changing a clocks problem too in March 2019. We just have to wait for member countries till 2021. One problem less for humanity and one new challenge for developers who need to fix and update their libraries.
Conclusions
Use a good library whenever you are going to deal with dates and time zones especially that “the rules” can change in time. Flightradar24 and flight booking websites seem to do a great job in this field. I am curious how complex test cases do they use…
What are your best bugs related to time calculation?
Software engineer with a passion. Interested in computer networks and large-scale distributed computing. He loves to optimize and simplify software on various levels of abstraction starting from memory ordering through non-blocking algorithms up to system design and end-user experience. Geek. Linux user.