In the previous blog entry ‘Time-out-of-joint’ 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 – millennium, leap seconds. Software I develop doesn’t move anywhere – it sits in a data centre I even don’t know where, let dev-ops 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 – time-zones.

People learn about time-zones 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 https://en.wikipedia.org/wiki/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 time-zones 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 time-zone (GMT+3) and some – GMT, ‘started’ field in the sessions table didn’t have time-zone 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 time-zone and marked as ‘Started at 7 A.M.’. After that periodic job started from a host with Moscow time-zone 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: Time-zones 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 time-zones 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 time-zones in the system is not enough for Java to become aware of them – you should change time-zones in Java as well. Of course there’s a special tool ‘tzupdater’ https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html to keep Java time-zones up to date, but it’s rarely used by system administrator on a regular basis and even if software vendor issued a time-zone 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.