Photo by Markus Spiske on Unsplash

Devs and Time Clock Rollovers

Let’s party like it’s 1999!

You have probably written programs with a bug related to the calculation of time (I certainly have!). For example, you need to work out the number of days there is between two dates, such as between 29 November and 20 December, and calculate:

Days = Date (20,12) — Date (29,11)

and we get 21 days. And you remember that we will have a problem if we calculate over the New Year:

Days = Date (4,1) — Date (29,11)

So we add in the year, and we can determine the right number of days. But many developers just look at the last two digits in the year, and then perform their calculation, so that the days between 1/1/16 and 1/1/19 is three times the number of days in each year. But what happens when we roll over from 2019 to 2020?

Let’s party like it’s 1999!

So, at the start of the 21st Century, we had a problem in that developers had often using the last two digits of the year to perform their time calculations. This caused the Millennium Bug, and where many worried that control systems would crash when the 21st Century arrived. Luckily, the bugs had been mostly identified and it passed without many problems. Developers were told that they should always use system time calls which included the year in their calculations.

And so, this week, I received this:

And it basically sad that Splunk had a little bug around the turn-over of the date from 2019 to 2020. It looks like the code had just looked — as with the Millennium Bug — at the last two digits of the year, and that search functions could give the wrong result (and even where data could be deleted).

It relates to the processing of the datatime.xml file (see below), and which is used regular expression in order to parse incoming data. Unfortunately it only uses two digits of the data, and will not work correctly when the date rolls-over from 2019 to 2020. It is thought that it may either create an exception on the processing of data, or put the wrong timestamp. It is thought that the bug will start occurring on 13 September 2020 at 12:26 (UTC). There is an update to datatime.xml (and which is stored in the etc folder) here:

http://download.splunk.com/products/ingest2020/datetime.zip

The bug is contained in here:

and the updated version is:

With this “[9012]” identifies that the year can contain a “2”, and which is missing in the previous version. If you are interested, here’s the updates in the regular expressions:

Conclusions

Luckily, Splunk have a strong bug fix programme, and hopefully things will all be patched in good time, otherwise, planes could fall out of the sky, as Splunk is used in some many industries now. BTW, we love using Splunk for Big Data analysis, and here’s a tutorial:

If you want a login, just ask.

ASecuritySite: When Bob Met Alice

This publication brings together interesting articles related to cyber security.

Prof Bill Buchanan OBE

Written by

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. EU Citizen. Auld Reekie native. Old World Breaker. New World Creator.

ASecuritySite: When Bob Met Alice

This publication brings together interesting articles related to cyber security.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade