My profile is US/Eastern TZ based. I checked for every hour from 2022-01-01 to 2023-01-01 for a few TZs, to ensure all clock changes are covered 1. Most of the MET<->US/Eastern conversion is incorrect  | makeresults | eval t0="2022-04-12 04:04", t=strptime(t0, "%F %H:%M"), from_tz="MET", to_tz="US/Eastern" | eval from_t=strptime(strftime(t, "%c.%6N " . from_tz), "%c.%6N %Z"), to_t=strptime(strftime(t, "%c.%6N " . to_tz), "%c.%6N %Z"), offset=round((from_t-to_t)/60/60), converted=strftime(t + (from_t-to_t), "%Y-%m-%d %H:%M") | append [makeresults| eval t0="2022-04-12 04:04", t=strptime("2022-04-12 04:04", "%F %H:%M"), to_tz="MET", from_tz="US/Eastern" | eval from_t=strptime(strftime(t, "%c.%6N " . from_tz), "%c.%6N %Z"), to_t=strptime(strftime(t, "%c.%6N " . to_tz), "%c.%6N %Z"), offset=round((from_t-to_t)/60/60), converted=strftime(t + (from_t-to_t), "%Y-%m-%d %H:%M") ] | table t0, converted, from_tz, to_tz   Actual Result:   Expected Result: 2022-04-12 04:04 MET = 2022-04-11 22:04:00 US/Eastern 2022-04-12 04:04 US/Eastern = 2022-04-12 10:04:00 MET   I got the total count: 5209 results of 8761 tests were incorrect, compared with the Python converted one. 8761 = 24 * 365 + 1   2. From other regions to US/Eastern, one year there's one hour incorrect Other regions tested: Asia/Seoul, Australia/Sydney,Europe/London,Europe/Paris,GB-Eire,GMT,Japan from python_to splunk_to 2022-03-13 02:03:00 GB-Eire 2022-03-12 21:03:00 US/Eastern 2022-03-12 22:03:00 US/Eastern 2022-03-13 02:03:00 GMT 2022-03-12 21:03:00 US/Eastern 2022-03-12 22:03:00 US/Eastern 2022-03-13 02:03:00 Japan 2022-03-12 12:03:00 US/Eastern 2022-03-12 13:03:00 US/Eastern 2022-03-13 02:03:00 Asia/Seoul 2022-03-12 12:03:00 US/Eastern 2022-03-12 13:03:00 US/Eastern 2022-03-13 02:03:00 Europe/London 2022-03-12 21:03:00 US/Eastern 2022-03-12 22:03:00 US/Eastern 2022-03-13 02:03:00 Australia/Sydney 2022-03-12 10:03:00 US/Eastern 2022-03-12 11:03:00 US/Eastern 2022-03-13 02:03:00 Europe/Paris 2022-03-12 20:03:00 US/Eastern 2022-03-12 21:03:00 US/Eastern 2022-04-03 02:04:00 Australia/Sydney 2022-04-02 11:04:00 US/Eastern 2022-04-02 12:04:00 US/Eastern   Use the 2022-03-13 02:03:00 Australia/Sydney as an example, per Time Converter and World Clock - Conversion at a Glance - Pick best time to schedule conference calls, webinars, online meetings and phone calls. (worldtimebuddy.com) The correct result should be 2022-03-12 10:03:00 US/Eastern instead of 2022-03-12 11:03:00 US/Eastern 3. From US/Eastern to other regions From Region To Region Error Count Total Test US/Eastern Asia/Seoul 27 8761 US/Eastern Australia/Sydney 60 8761 US/Eastern Europe/London 19 8761 US/Eastern Europe/Paris 23 8761 US/Eastern GB-Eire 19 8761 US/Eastern GMT 9 8761 US/Eastern Japan 27 8761   Conclusion: MET<-> US/Eastern conversion has many errors and can't be used in production Other Regions->US/Eastern result is acceptable US/Eastern->Other regions has some errors around the clock change dates. Depends on the requirement it could be used. Finally - why Splunk doesn't provide native TZ Conversion function is a question.  ... View more

  @EvilPuppetMaste wrote: Improving on the answer above, here is a version that DOES account for daylight savings timezones, as well as times with microseconds: | makeresults | eval t=strptime("2017-01-01 14:00", "%F %H:%M"), from_tz="UTC", to_tz="Australia/Melbourne", from_t=strptime(strftime(t, "%c.%6N " . from_tz), "%c.%6N %Z"), to_t=strptime(strftime(t, "%c.%6N " . to_tz), "%c.%6N %Z"), offset=round((from_t-to_t)/60/60), converted=strftime(t + (from_t-to_t), "%c") It can be simplified for brevity, I've just broken it into different variables to make it easier to follow. 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. Note that if you put in explicit DST timezone names like 'AEDT' then it will ALWAYS be daylight savings, regardless of the date. 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. The list of timezone names appear to be the standard list from Java.   This solution is incorrect. Try below, convert 2022-11-06 01:10 US/Eastern and 2022-11-06 02:10 US/Eastern to Australia/Sydney time, you get 2022-11-06 15:10(Incorrect) and 2022-11-06 18:10(Correct) Sydney time respectively. The way to calculate the two time zone's time gap is incorrect: It assumes the gap is 2022-11-06 01:10 US/Eastern and 2022-11:06 01:10 Australia/Sydney. When it approaches to the clock change hour(i.e. 2022-11-06 02:00 AM) the error happens   | makeresults | eval t=strptime("2022-11-06 01:10", "%F %H:%M"), from_tz="US/Eastern", to_tz="Australia/Sydney", from_t=strptime(strftime(t, "%c.%6N " . from_tz), "%c.%6N %Z"), to_t=strptime(strftime(t, "%c.%6N " . to_tz), "%c.%6N %Z"), offset=round((from_t-to_t)/60/60), converted=strftime(t + (from_t-to_t), "%Y-%m-%d %H:%M") | append [| makeresults | eval t=strptime("2022-11-06 02:10", "%F %H:%M"), from_tz="US/Eastern", to_tz="Australia/Sydney", from_t=strptime(strftime(t, "%c.%6N " . from_tz), "%c.%6N %Z"), to_t=strptime(strftime(t, "%c.%6N " . to_tz), "%c.%6N %Z"), offset=round((from_t-to_t)/60/60), converted=strftime(t + (from_t-to_t), "%Y-%m-%d %H:%M") ] | fields converted, from_tz, to_tz | table converted, from_tz, to_tz ... View more