Let’s party like it’s 1999!

让我们狂欢吧，就像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:

您可能编写了与时间计算有关的错误的程序(我当然有！)。 例如，您需要计算两个日期之间的天数，例如11月29日至12月20日，然后计算：

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

天=日期(20,12)-日期(29,11)

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

我们有21天的时间 您还记得，如果在新年期间进行计算，我们将遇到问题：

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

天=日期(4,1)-日期(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?

因此，我们加上年份，就可以确定正确的天数。 但是许多开发人员只是查看一年中的最后两位数字，然后进行计算，因此1/1/16到1/1/19之间的天数是每年天数的三倍。 但是，当我们从2019年过渡到2020年时会发生什么？

让我们狂欢吧，就像1999年一样！ (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.

因此，在21世纪初，我们遇到了一个问题，即开发人员经常使用一年的最后两位数字来进行时间计算。 这导致了千年虫 ，许多人担心21世纪到来时控制系统会崩溃。 幸运的是，大多数错误已被识别出来，并且顺利通过了许多问题。 开发人员被告知，他们应始终使用系统时间调用，其中应将年份包括在计算中。

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).

基本上令人难过的是，Splunk在2019年至2020年的日期变更期间存在一个小错误。看起来该代码就像在千年错误中一样，只在一年的最后两位数字出现了，并且进行了搜索函数可能会给出错误的结果(甚至可以删除数据)。

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:

它涉及datatime.xml文件的处理(请参见下文)，并使用正则表达式来解析传入的数据。 不幸的是，它仅使用两位数的数据，并且当日期从2019年过渡到2020年时将无法正常工作。据认为，这可能会在数据处理方面产生异常，或者会放置错误的时间戳。 据认为，该错误将从2020年9月13日12:26(UTC)开始发生。 这里是datatime.xml的更新(存储在etc文件夹中)：

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

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

The bug is contained in here:

该错误包含在这里：

<!--   Version 4.0 --><!-- datetime.xml --><!-- This file contains the general formulas for parsing date/time formats. --><datetime><datetime><define name="_year" extract="year"> <text><![CDATA[(20\d\d|19\d\d|[901]\d(?!\d))]]></text></define>..</datetime>

and the updated version is:

并且更新的版本是：

<define extract="year" name="_year"><text><![CDATA[(20\d\d|19\d\d|[9012]\d(?!\d))]]></text></define>..</datetime>

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:

使用此“ [9012]”标识年份可以包含“ 2”，并且在以前的版本中缺失。 如果您有兴趣，这里是正则表达式中的更新：

Comparing files datetime.xml and D:\DATETIME.XML***** datetime.xml<define name="_year" extract="year">        <text><![CDATA[(20\d\d|19\d\d|[901]\d(?!\d))]]></text></define>***** D:\DATETIME.XML<define name="_year" extract="year">        <text><![CDATA[(20\d\d|19\d\d|[9012]\d(?!\d))]]></text></define>********** datetime.xml<define name="_masheddate" extract="year, month, day">        <text><![CDATA[(?:^|source::).*?(?<!\d|\d\.|-)(?:20)?([901]\d)(0\d|1[012])([012]\d|3[01])(?!\d|-| {2,})]]></text></define>***** D:\DATETIME.XML<define name="_masheddate" extract="year, month, day">        <text><![CDATA[(?:^|source::).*?(?<!\d|\d\.|-)(?:20)?([9012]\d)(0\d|1[012])([012]\d|3[01])(?!\d|-| {2,})]]></text></define>********** datetime.xml<define name="_masheddate2" extract="month, day, year">        <text><![CDATA[(?:^|source::).*?(?<!\d|\d\.)(0\d|1[012])([012]\d|3[01])(?:20)?([901]\d)(?!\d| {2,})]]></text></define>***** D:\DATETIME.XML<define name="_masheddate2" extract="month, day, year">        <text><![CDATA[(?:^|source::).*?(?<!\d|\d\.)(0\d|1[012])([012]\d|3[01])(?:20)?([9012]\d)(?!\d| {2,})]]></text></define>********** datetime.xml<define name="_utcepoch" extract="utcepoch, subsecond">        <!-- update regex before '2017' -->        <text><![CDATA[((?<=^|[\s#,"=\(\[\|\{])(?:1[012345]|9)\d{8}|^@[\da-fA-F]{16,24})(?:\.?(\d{1,6}))?(?![\d\(])]]></text></define>***** D:\DATETIME.XML<define name="_utcepoch" extract="utcepoch, subsecond">        <!-- update regex before '2023' -->        <text><![CDATA[((?<=^|[\s#,"=\(\[\|\{])(?:1[0123456]|9)\d{8}|^@[\da-fA-F]{16,24})(?:\.?(\d{1,6}))?(?![\d\(])]]></text></define>*****

结论 (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:

幸运的是，Splunk具有强大的错误修复程序，希望一切都可以在适当的时间修补，否则，飞机可能会掉下来，因为Splunk现在已在许多行业中使用。 顺便说一句，我们喜欢使用Splunk进行大数据分析，这是一个教程：

If you want a login, just ask.

如果要登录，请询问。