Отображать дату в местном Timzone, а не в формате UTC в AWS Quicksight - PullRequest
0 голосов
/ 10 ноября 2018

Итак, читая документы AWS Quicksight, я нашел следующую информацию.

Обработка даты и времени Часовые пояса:

Amazon QuickSight использует время UTC для запросов, фильтрации и отображения данных о дате. Если данные даты не указывают часовой пояс, Amazon QuickSight принимает значения UTC. Когда данные даты указывают часовой пояс, Amazon QuickSight преобразует его для отображения в формате времени UTC. Например, поле даты со смещением часового пояса, например 2015-11-01T03: 00: 00-08: 00, преобразуется в UTC и отображается в Amazon QuickSight как 2015-11-01T15: 30: 00.

У меня есть набор дат в наборе данных Athena, который я анализирую в Quicksight. Я хотел бы иметь возможность просматривать эти даты в Quicksight как местное представление часового пояса, а не как формат UTC. Кто-нибудь может посоветовать, какой будет наилучший подход для этого или если это вообще возможно? Кажется, если я использую вычисляемую функцию поля, такую ​​как formatDate (), или даже пользовательский SQL 'AT TIME ZONE', тогда мои столбцы даты преобразуются в строки. Тогда любая попытка преобразовать эти строки обратно в дату просто конвертирует дату обратно в формат UTC.

Я попытался преобразовать возвращенную строку даты с помощью:

parseDate({NEWDATE}, "yyyy-MM-dd HH:mm:ss.SSS ZZZ", "Australia/Melbourne")

Однако, это продолжает вызывать ошибку «Эта функция не имеет правильного количества аргументов».

Любой совет приветствуется.

Ответы [ 2 ]

0 голосов
/ 19 марта 2019

Была такая же проблема с formatDate, возвращающим строку и parseDate, не поддерживающим SPICE. В конце концов, следующее решение сработало для меня.

parseDate(formatDate({DATE}, 'yyyy-MM-dd', 'America/New_York'))

formatDate возвращает строку в необходимом часовом поясе, а parseDate преобразует ее обратно в дату. Я не нашел способа сэкономить время, возможно, из-за проблем с parseDate в SPICE, но это не имело большого значения, так как меня интересуют даты.

0 голосов
/ 29 ноября 2018

Я столкнулся с подобной проблемой. В качестве обходного пути (который не обрабатывает DST), вы можете использовать функцию addDateTime.

Например:

  • Расчетное имя поля: datetimemelbourne
  • Формула: addDateTime(11, 'HH', {datetime})
...