bug: wrong timezone displayed for awk helper datetime()

IKL Development
#1

I'm using the awk helper function datetime(year, month, day, hour, minute, second) to parse a date-time. But, when I display the datetimes in the live config, the timezones are incorrect; these should be UTC:

Image title


I would think that datetime() is assuming UTC for the timezone. I haven't checked the actual seconds since the epoch -- maybe this is (somehow) just a display bug.

#2

You are correct, it does assume UTC timezone.


I'm not exactly sure about the display in the UI, but perhaps it corresponds with your local timezone?

#3

@Eyal_Roth @Hawkeye_Parker I want to revive this thread as I am running into the exact same issue.

I am writing a script to parse a date time string into epoch time.
The script:

#! META

name: cas-show-ssl

description: Show list of certificates on the management (VPN, SIC etc) in MDS

type: monitoring

monitoring_interval: 59 minutes

requires:

vendor: "symantec"

os.name: “cas”

#! COMMENTS

certificate-expiration:

skip-documentation: true

#! REMOTE::SSH

show ssl | display json | exclude contents | nomore

#! PARSER::JSON

Example input shown below. The timezone is always on UTC.

“valid-until”: “2037-12-01T11:59:59-00:00”

_metrics:

-

    _groups:

        $.data.ssl:ssl.ca-certificates[0:]:

            _tags:

                "live-config":

                    _constant: "true"

                "display-name":

                    _constant: "Certificate Expiration"

                "im.identity-tags":

                    _constant: "name"

                "[im.name](http://im.name/)":

                    _constant: "certificate-expiration"

                "im.dstype.displaytype":

                    _constant: "date"

                "name":

                    _value: "id"

            _temp:

                "expiration":

                    _value: "valid-until"

    _transform:

        _value.double: |

            {

                datestring = temp("expiration")

                gsub(/-|T|:/, " ", datestring)

                split(datestring, dateArray, / /)

                month = dateArray[2]

                day = dateArray[3]

                year = dateArray[1]

                hour = dateArray[4]

                minute = dateArray[5]

                second = dateArray[6]

                secondsSinceEpoch = datetime(year, month, day, hour, minute, second)

                print secondsSinceEpoch

            }

partial input:

{

      "id": "VRSN_Class_4_Pub_G3",

      "subject": "\n/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 4 Public Primary Certification Authority - G3\n    ",

      "issuer": "\n/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 4 Public Primary Certification Authority - G3\n    ",

      "valid-from": "1999-10-01T12:00:00-00:00",

“valid-until”: “2036-07-16T11:59:59-00:00”,

      "fingerprint": "\nC8:EC:8C:87:92:69:CB:4B:AB:39:E9:8D:7E:57:67:F3:14:95:73:9D\n    ",

      "contents": "content"

    },

partial output:

{

"type": "ts",

"tags": {

  "name": "VRSN_Class_4_Pub_G3",

  "im.identity-tags": "name",

  "im.dstype.displaytype": "date",

  "im.name": "certificate-expiration",

  "live-config": "true",

  "display-name": "Certificate Expiration"

},

“value”: 2099858399,

"timestamp": 1541299584595

},

image.png

My computer is on Honolulu timezone which is UTC-10
test.json:

{

“nameToCase”: {

"multiple-entries-utc-timezone": {

  "timezoneId": "Pacific/Honolulu",

  "inputPath": "multiple-entries-utc-timezone/input.json",

  "outputPath": "multiple-entries-utc-timezone/output.json"

}

}

}

The Question:

The documentation for datetime function says it should return the date as epoch, https://indeni.atlassian.net/wiki/spaces/IKP/pages/54198317/AWK+Helper+Functions#AWKHelperFunctions-Datemanipulationfunctions.

If the datetime function is translating the date string with the timezone of the computer it’s running on, then the output makes sense but then the script becomes timezone sensitive to where the script is running. If this is the case, it would be really bad if Indeni server is on non UTC time zone, because all date time related metric would be incorrect. The question is “is this expected behavior?” and “If so, can Indeni server be on non UTC timezone?”

Thanks

#4

Again, the datetime AWK parser function always uses UTC, regardless of the machine timezone.

The extracted value you got is 2099858399, which is exactly the amount of seconds (not milliseconds) between beginning of epoch time (1970) and July 16 2036, 11:59:59 AM UTC.

There is also the timestamp value which is epoch time (in milliseconds) in which the metric was created; i.e, the time when you ran the parser.

#5

@Eyal_Roth, 2099858399 is not equal to July 16 2036, 11:59:59 AM UTC. See screen shot below:

image
image730×350 20.1 KB

However it is equal to July 16 2036, 11:59:59 AM HST, where HST is UTC - 10. Do you know what’s causing this?

Thanks
Josh

#6

@Josh_He You are absolutely right.

I got it wrong for some reason (twice). There is actually a bug already open for this on our platform: IS-2735.

#7

@Eyal_Roth Thanks for the info! Do you know when it will be fixed?

Thanks
Josh

#8

@Josh_He Unfortunately there is no time estimation at the moment, as this has to be prioritized against other tasks :frowning_face: