How to handle a scripted bash input with an international date stamp when my Splunk instance is in a US timezone?

[BP9906]

Hello,
What is the best way to handle a scripted input so that it echoes the date in a format Splunk can interpret easiest?

Currently I use the date command, example:

echo "`date` permission=\"BLOCKED\" user=\"$item\""

It echoes to stdout as:

Sat Sep 24 08:30:32 EST 2016 permission="ALLOWED" user="root"

In this case the EST is Australian (Sidney) timezone.

cat /etc/sysconfig/clock 
ZONE="Australia/Sydney"
UTC=true
ARC=false

Splunk search heads and indexers are in US time zones so I'm receiving "delayed" data whereby searching for this data for the last hour is actually data from many hours ago.

How do I avoid this behavior for my international systems?

Thank you.

[lguinn2 · Accepted solution]

Ah - you need to tell Splunk to use the Australia time zone instead of the USA time zone.

You do that by setting the time zone alias in props.conf, probably like this:

[default]
TZ_ALIAS = EST=GMT+10:00

Although you could also set up the alias for just particular sourcetypes or hosts. Look this up in the docs under Map timezone strings extracted from event data in the middle of this page on timestamps.

[BP9906]

Thank you for your response. Perhaps the answer I was looking for was such that I could trigger this instead:

If the forwarder and the receiving indexer are version 6.0 or later, use the time zone that the forwarder provides.

Linux date will always print the abbreviated timezone so I'm trying to avoid any added configuration because your suggestion means every source (scripted input) I will need to add that or set it for each host. It just doesnt scale very well.

I'm going to try this instead and see if it will trigger the above quoted block from the article you reference.

date +%F\ %H:%M:%S

[BP9906]

It seems the above works great to resolve my issue.
I've run sed on them to fix them all.

sed -i.20160926 's#`date`#`date +%F\ %H:%M:%S`#' <file>

[aaraneta_splunk]

Hi @BP9906 - Glad to hear that @lguinn's answer was helpful to you. Please don't forget to resolve your post by clicking "Accept" below her answer. Thanks!