![]() Hi and thank you for pointing out that my comment was not fully explained. This gives Splunk enough information to assign the correct time to the event, but also allows us to run queries against the local time where the data is sourced from. For our use case, we are uploading the 'real world time' using time since Epoch (assigned to the _time property), and additionally upload a timestamp field formatted as a date in local time which Splunk interpets as a string. use a different field other than the _time property). If you wish to run a query using local time of an area which is not always a fixed offset from UTC, then you will have to upload a timestamp to Splunk in local time (of course this only applies if you are in control of your input sources) and not have Splunk interpret it (i.e. I believe this is because Sydney adheres to Day Light Savings time. For example, if you live in Sydney you would usually select the "Australia/Sydney" timezone from timezone dropdowns - however this item is not available in Splunks list of timezones in the user preferences. ![]() Splunk does not seem to support the tz database - it only seems to support timezones with a fixed offset from UTC.However I have found that when passing arguments to a macro it is best to use pre-calculated fields, rather than expressions (since expressions will have their " quotes stripped when passed as arguments to a macro). The above can easily be converted to a macro.Using the above method will not break under such circumstances. I discovered that Splunk Light Version 6.4.1.2 seems to have a bug where it ignores the users timezone and always reports UTC.Instead, whenever printing this date always include the timezone manually and don't use the %Z timezone formats (as is done in the last line of the example). in the example, Splunk interprets the _time_AEST variable as seconds since epoch ( 00:00:00 UTC), and so technically Splunk is interpreting this as a different 'real world' time - if you attempt to print the timezone of the date, it will incorrectly report the users configured timezone.The UTC offset of the two timezones in question is calculated by using a reference date (I chose arbitrarily) and parsing it twice, first using the UTC timezone and then the queried timezone, and the difference of the two yields the timezone offset. The above works by first subtracting the UTC offset of the timezone as configured in the users preferences, then adds on the UTC offset of the timezone you configure (in this example AEST, but could be -05:30 or any valid Splunk timezone identifier). | eval time_in_AEST = strftime(_time_AEST, "%F %T ". does not support day light savings time). Inspired by the excellent answers provided here, it is possible to convert to an arbitrary timezone provided that timezone always has a fixed UTC offset (i.e. The list of timezone names appear to be the standard list from Java. But other timezone names (like Australia/Melbourne used in the example), which are sometimes DST and sometimes not, will change offset according to the input date. Note that if you put in explicit DST timezone names like 'AEDT' then it will ALWAYS be daylight savings, regardless of the date. Also the offset variable is unused, but is just there so you can experiment by changing dates and timezones to see that the offset does actually change depending on whether daylight savings is applicable for the date. It can be simplified for brevity, I've just broken it into different variables to make it easier to follow. Improving on the answer above, here is a version that DOES account for daylight savings timezones, as well as times with microseconds: | makeresultsįrom_t=strptime(strftime(t, "%c.%6N ".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |