Hi this problem is NOT SOLVED. Please do not mark it as solved. I am having to same issue. To be clear, any case with DAILY data is NOT fixed with a solution utilizing calculated fields.
The date filter, when using relative dates, is set to UTC. Why? This is a terrible take for production. 4pm PST rolls by, and some people are wondering why the relative date which says “previous day” is showing incorrect data. Well, it is showing data that is technically today, because 4PM PST is 12AM UTC.
I would like to hear about when this can be changed, since no solution seems to be present online. @SeanBoon please let us know, it’s coming up on 12 months.
Hi All, thanks for the discussion here. Time Zone is always a hot topic. Let me try to summarize the current capability of QuickSight and try to clarify some confusions here.
Currently, there is no time zone concept in QuickSight, if user ingest the datetime with their own time zone as @FABIOLA_PICHARDO 's case, SPICE wouldn’t do the conversion, it would store the date as is and ignore the time zone information. QuickSight Analysis also doesn’t carry the time zone concept, meaning when dataset is added to the analysis, it is always directly using the literal time from the dataset (SPICE and other Direct Query data sources), doing no conversions. With those cases, if user stores their datetime in the data source at their own time zone, all the display and aggregation/calculation will be with that time zone. Many cases would work fine. The user would know what time zone their dashboards are with, but QuickSight wouldn’t know.
If users want to do some conversions manually in the analysis on top of the data source, they can use the adddatetime() to add or subtract the offset to convert their datetime from the original time zone to the new time zone, and can use those complicated ifelse to deal with daylight savings, as suggested by @Naveed. Again in those cases, QuickSight is treating the datetime as literals, no underlying time zone native support.
However, for QuickSight objects, such as filter/parameter, when they are defined in analysis, the semantic meaning of the phrases such as “start of this week” or “yesterday” are treated as UTC, and currently we don’t have the capability for users to customize that. That’s why if your original data source is not in UTC, you would see that discrepencies.
To provide native support for time zone conversion is a known request and we are currently working on it. The detailed requirements are being worked at. If any of you are interested in further discussion, feel free to message me offline. We are happy to work together to address your need and share more information.
@emilyzhu This is the true answer. This is not “solved”, please leave this unsolved as a feature request. I need solutions, this is being deployed in a business as a service, and can’t have such a simple functionality unresolved without turning heads and devaluing the service.