I've been using Manage Time Zone for a couple years now and I just recognized this week (one of my team members brought it to my attention) that the time zone is not converting properly.
I have an example table below which pulls login times from our API, which contains the date time value in UTC. You can see that here. For example, this is a known login time of 8:58 AM MT, which converts properly to 3:58 PM UTC previous day.
I then have the column configured like this, and it is displaying the incorrect conversion. It is rendering the suffix I configured for my local time zone (I'm in Eastern and he is in Mountain). But its actually rendering UTC time as the display.
Is there perhaps a default timezone that was introduced somewhere that I need to account for now? This is happening for all of my tables which leverage this feature.
Anyone have an idea here? This feels like a bug since I don't recall doing anything to change this. But, if there's something I can do to handle it, I'm happy to.
Thanks Kenny. It seems like something about the new table component caused a regression for the previous one. It seems like there are 3 states, Legacy, updated legacy (I don't know what to call this, but its evident it existed because I had the option to downgrade to legacy), and new tables. I could not get anything to work with the previous table types. Downgrading, adjusting the manage time control options, etc. However, building a new table (with the most up-to-date table component) and reformatting all of my data resolved the issue. Unfortunately that was a lot of work since my data source has a lot of columns.
The other thing I noticed is that the zzz part of the time zone formatting used to return the friendly timezone like "EST." Though the actual numeric time is proper now, it is returning GMT -5 instead of the friendly name. I've tried both z, zz, and zzz and all of them end up rendering GMT-5 (my local timezone). Is there a way to render EST, EDT, MST, MDT, etc again?
I'm sorry about the extra work you had to do on your end to make this workaround. We looked into this issue, the reason your table stopped rendering the correct time is due to an update from a few months ago, where we changed the way we validate Date strings. The format YYYY-MM-DD HH:MM:SS.ssssss ±hhmm is currently failing a check for a valid ISO string.
Another workaround is to transform the timestamp into a format that will pass our current validation (eg 2024-02-21T16:01:12.328Z), using the column's "Mapped Value" field:
But it sounds like you got that part working already so no need to update your table.
On the other hand, I tried to render the desired timezone (e.g PST) on the column by modifying the "Time format" under "Appearance", and even hard coding it directly on the "Mapped value" doesn't do the trick:
If hard coding it would have worked, we could have made a JS function that takes care of parsing the last part of our string, but it looks like this is not possible at the moment. I created a feature request for this. I'll keep you posted with any updates on it.
Thanks for the work on this Paulo. It's at least good to confirm I'm not crazy! I think for the time being the updated tables are serving the purpose I need. The key was that my team was making inaccurate conclusions because the actual time displayed was wrong. Now that's corrected and we're good.
Hi @Leor_Alon, our devs are still working on this issue. If the workaround mentioned above does not work for you, we could also add a “Suffix text” add-on to display the desired timezone:
