1 of 1 people found this helpful
This is a fun one! I can't find much info on using the "x" nomenclature to convert timezones in tableau.
You could try something like this:
DATEADD('hour', INT(MID([Created_At],21,2)), DATEPARSE("yyyy-MM-dd'T'HH:mm:ss",[Created_At]))
That gets you back to GMT. Found it on this post: Re: convert string to GMT timezone
Thanks for taking a look! Any idea why the 'x' timezone code isn't working for DateParse? That date format code page is linked to from the Understanding the DATEPARSE Function | Tableau Software KB article so I figured it'd be supported. I can use the adventures in DateAdd in the meantime, but I'd love to know if there's some gap in our dateparse() formula or if I'm just using it wrong.
2 of 2 people found this helpful
After reading this thread – and after several unsuccessful attempts to make time zone work – I created the idea request DATEPARSE Time Zone. I assume you are interested in up-voting it and thus influence Tableau to support time zones in DATEPARSE.
Thanks! I think that's where this was ultimately heading. Glad to hear I'm not missing something obvious.
The omission of time zone examples in Understanding the DATEPARSE Function | Tableau Software convinced me that DATEPARSE doesn't support time zone. Oh, how I wish what is not supported also is mentioned! At least when it can be compared with a checklist which is referred to in the same article!
I think the idea post is fine without the expected resulting timestamps. From looking at previous posts and http://community.tableau.com/ideas/2607, Tableau will just return the time in whatever timezone the data is stored in, no conversion to local/UTC/otherwise.
Thank you for taking time for this. It is appreciated.
Tableau will just return the time in whatever timezone the data is stored in, no conversion to local/UTC/otherwise
I am a little bit confused since DATEPARSE already can return locale time by cutting off time zone suffix as shown here:
Was 2015-02-20 20:18:48 all you wanted from shown DATEPARSE example?
I think the idea post is fine without the expected resulting timestamps
I am a strong believer in sharing examples, because they make ideas easy to understand and thus reveal their strengths and weaknesses. If sharing examples is a weakness in this case, then I assume it is because the idea itself is weak and not needed, or because it was poorly presented.
In this regard, it was rather poorly presented, because the examples seemed to indicate that the idea was limited to them. This is hereby corrected so it now explicitly mentions inclusion of all time zone inputs and outputs in the UCI standard.
I still see some value in this idea and therefore leave it open for voting.