latest = -0d@d is broken for users in time zones when daylight savings starts and clock switches over. We observed this issue with search time range preset = yesterday as well for 'America/Santiago' timezone as DST started today.

[neovenkat]

We had set the time zone as 'America/Santiago' for user tz_user. Today DST started for America/ Santiago time zone. When we logged in as tz_user we got the error 'Invalid value "-0d@d" for term latest' for the below query:

|tstats count from datamodel=foo where earliest=-1d@d latest=-0d@d

Why is Splunk behaving like this for only time zone that is under going this transition?

[martin_mueller · Accepted solution]

Looking at https://timezonedb.com/time-zones/America/Santiago I see

After Saturday, 11 August, 2018 11:59:59 PM:
Clocks were moved forward to become Sunday, 12 August, 2018 01:00:00 AM

Your latest time of @d is trying to refer to August 12th, 00:00:00 or midnight. That time doesn't exist in the Santiago timezone. Nothing splunk can do about that.

[strive]

The daily scheduled searches are going to be affected because of this. Is there any workaround for this for daily scheduled searches.

Whats happening is:
The daily scheduled search reruns automatically for all the days from the beginning till DST start date and thus creating duplicate summary data. This is because splunk is not able to resolved the time modifier snapped to day.

Any workarounds for this would be highly appreciated.

Meanwhile a case has been raised with Splunk to look into this issue.

[martin_mueller]

No, the dashboards shouldn't show empty values. That time doesn't exist, there are no buckets that could be empty.

See how the six ten-minute buckets are missing? That time doesn't exist.
What splunk could improve is handling what happens when you refer to a non-existing time with @d, if you feel that way you should open a support case. Even better, open a support case with local governments to abolish DST, or at least not use DST in a way that makes midnight not happen.

[strive]

Thank you. Looks like the pre-built dashboards where -0d@d has been used should be changed to handle previous day case.

It will be better if Splunk changes the error message. From end user perspective he/she is right when they pick Yesterday option from Time Range Picker presets. That time users will be lost if SPlunk just displays a error message like this: 'latest_time must be greater than earliest_time'.

[strive]

If that is the case then the dashboards should show empty bucket from 00:00:00 to 01:00:00 since the time 00:00:00 doesn't exist. But that is not the case. The dashboards show values for that particular hour.

[martin_mueller]

Note, your tstats search fails everywhere - specify +Xd or -Xd, not Xd because that's invalid.

[neovenkat]

Sorry I have edited it should be latest=-0d@d. Thanks for the detailed info below.