Handling Time Zone Not Support

I am using presto through AWS Athena and trying to take user generated events in UTC and convert them to the users own time zone. I am not sure if it’s due to Athena’s version of presto not being up to date, but some users have time zones that presto doesn’t recognize. In my case it’s 'Asia/Yangon'

SELECT at_timezone(timestamp '2020-01-01', 'Asia/Yangon')

NOT_SUPPORTED: Time zone not supported: Asia/Yangon

Unfortunately, I don’t have the ability to update Athena’s version of presto if that would solve this. Even if I were able to, it’s possible a user reports a new or non-existing time zone at any time, breaking any query that uses at_timezone that happen to include their events.

I tried using a try here but it doesn’t catch this type of error.

SELECT try(at_timezone(timestamp '2020-01-01', 'Asia/Yangon'))

Is there a way I can safely attempt to change the time zone of a timestamp, or is there a list of valid time zones for presto I can filter on?

[micah-williamson]

That’s all. I didn’t know if you wanted to leave it open if the try was supposed to catch this error.

[micah-williamson]

Thank you for that list. With it i was able to easily find which time zones Athena’s version of presto is unable to match. With that I can create a fallback. From our data we could map:

-- These time zones can match to another time zone in the same offset
America/Fort_Nelson => America/Denver
Asia/Barnaul => Asia/Novosibirsk
Asia/Tomsk => Asia/Novosibirsk
Europe/Astrakhan => Europe/Volgograd
Europe/Kirov => Europe/Istanbul
Europe/Ulyanovsk => Europe/Volgograd
America/Punta_Arenas => America/Sao_Paulo
Asia/Atyrau => Asia/Tashkent
Asia/Famagusta => Asia/Jerusalem
Europe/Saratov => Europe/Volgograd

-- This one doesn't exist in the current presto time zones list
Asia/Qostanay => Antarctica/Vostok

-- These time zones don't match any time zone in the same offset, and so are a closest approximation
Asia/Yangon => Asia/Bangkok
India/Cocos => Asia/Bangkok