It assumes the gap is 01:10 US/Eastern and 2022-11:06 01:10 Australia/Sydney. The way to calculate the two time zone's time gap is incorrect: Try below, convert 01:10 US/Eastern and 02:10 US/Eastern to Australia/Sydney time, you get 15:10(Incorrect) and 18:10(Correct) Sydney time respectively.
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. The list of timezone names appear to be the standard list from on the answer above, here is a version that DOES account for daylight savings timezones, as well as times with microseconds: | makeresults %z or %Z but again, depends on your use case.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 ". but maybe this isn't a problem for your use case.Īnother option may be to ignore the TZ issue, and just include a time zone indicator in your format string e.g. Now the drawback here is of course everyone who can read this search is running this search with the same Splunk role, so no per-user index filtering is happening at search time here. NOT with | savedsearch "searchName" ), the search will then execute as the owner instead of as the user, and magic, standardized TZs. using in SimpleXML or a ds.savedSearch datasource in Dashboard Studio. When your search is loaded in the dashboard by a reference (e.g. This report should be shared in app, readable by all roles who should be able to read and execute the searches on the dashboard, owned by a service account who has the correct timezone in their user preference, and configured to be Run As Owner) So a possible way around this, instead of having your search in your dashboard directly, you save the search as a saved report. When I display them in a table they display in whatever the user preference is for timezone. I'm not doing anything complicated right now, I'm just converting a UNIX timestamp with strftime: I feel like there must be some simple way to do this that I just haven't found. The reason for this requirement is that we have several members located globally that have a legitimate/more frequent need to have their own timezone (so we can't ask them to change to Eastern) but the dashboard in question specifically needs to report on issues using Eastern time (they need to look the same for everyone). essentially the requirement I have is to display a timestamp in a Splunk dashboard in a specific timezone, regardless of what user preferences people have configured. I spent a fair amount of time perusing Google and Splunk Answers but couldn't seem to find a solution that made sense.
0 kommentar(er)
