In the previous blog entry I wrote about various problems that can happen when nuances in time handling are not considered. Somebody may think: “Well, this all happens so rarely – millenium, leap seconds. Software I develop doesn’t move anywhere – it sits in a data center I even don’t know where, let devops think about time synchronization – I’m not paid for this. All this is fun but exotic like 7 bit byte”. Unfortunately, time may bring surprises to developers not only in marginal cases but in something that always exists – timezones.
People learn about timezones early. When I was a child, Soviet radio stations used to announce at 3 pm Moscow time: “Moscow speaks. Transmitting time signals. The beginning of the 6th signal corresponds to 3 pm Moscow time. It’s 3 pm in the capital, 4 pm in Askhabad, 5 pm in Tashkent, 6 pm in Karaganda, (list of cities with their times continued), it’s midnight in Petropavlovsk-Kamchatsky”. At that time the only thing I knew about that city was that it’s always midnight there. Even though we know about timezones from the childhood, some facts about them surprise developers.

Fact 1: Timezones exist.

I’d been working for one of the largest Russian Internet portals in the 90’s. When users logged in to it, a new session was created and after some time of inactivity it was considered expired and user was asked to re-login. One day a periodic job was set up to clean session database and users started complaining that they were kicked out right after login. It turned out that some hosts had Moscow timezone (GMT+3) and some – GMT, ‘started’ field in the sessions table didn’t have timezone information – this was just date + time. When user tried to log in at 10 A.M. Moscow time, its session was created by a host with GMT timezone and marked as ‘Started at 7 A.M.’. After that periodic job started from a host with Moscow timezone wiped it as outdated.

Fact 2: Summer time.

The switch to summer time happens in the US 2 weeks earlier than in the UK. Some team collaboration tools ignore this fact – they ‘think’ that if time was shifted in the US, it was shifted everywhere. Those 2 weeks are usually spent in endless attempts to adjust meetings and e-mails ‘We have a meeting scheduled at … , but please ignore this – it will happen at different time’. Of course this reoccurs every 6 months.

Fact 3: Timezones change.

In 2014 Russian government decided to cancel daylight saving time. There was a joke that a minister couldn’t figure out how to change time in his iPhone and decided to cancel it by law. Then the fun began – almost all devices from computers to cellphones and home electric meters unaware of new orders shifted time as they were programmed to do. We had to change time manually back and forth or set them to some esoteric timezones used in certain Arab countries to make the devices show the correct time.

To make things worse, if you’re running software platform like Java on top of an operating system, updating timezones in the system is not enough for Java to become aware of them – you should change timezones in Java as well. Of course there’s a special tool ‘tzupdater’ to keep Java timezones up to date, but it’s rarely used by system administrator on a regular basis and even if software vendor issued a timezone patch – chances are it would not be applied for a long time.

Underestimating the complexity of time problems may cause lots of troubles. Not only in Soviet Russia.

Leave a comment

Your email address will not be published. Required fields are marked *