@Polina_Zenevich what’s the best post to upvote to see timezones implemented sooner?
I find this part of the documentation rather concerning:
We will implement support for user timezones. Maybe. Some day. If you want to speed that up, feel free to ping us anywhere and share your pains/feedback about it!
as it makes Fibery a cumbersome choice for teams working in more than one timezone, which is many remote teams
Yes, that’s it. But for now, we don’t have a nice solution in mind. And development looks very complicated and will take a very long time in any case.
So we’re collecting cases and after all the “must-have” features will be done - maybe that is smth we’ll work on.
Feel free to initiate discussion in the Ideas&Features category - will be glad to hear more about current pains and see votes
I’m curious what your team is trying to do that isn’t supported by how timezones currently work? I read through it and it seemed to generally make sense, but maybe I’m not realizing what we are missing at the moment.
I think it’s referring to the ability to change the priority of the colour coding (relevant in the case where an item matches more than one criterion):
Timezone cannot be defined per user, and yet importing CSV times converts them to UTC (regardless of what timezone is specified in the CSV time fields) in a recursively buggy way.
I currently have items reading 18 hours skewed. I’ve been the only person in this workspace. I have always been UTC -6. I imported datasets in UTC after reading that Fibery only does UTC (actually I thought Fibery was THE ultimate remote teams solution because it only operated in UTC, but as I found I am mistaken in the way “only operates in UTC” actually functions in practice) …
…and unbenknownst to me, I proceeded to make a bunch of relations and formulas and 3 weeks and 18 datasets into developing this, I find no matter what I do I can’t get visually identical dates to return true on filters.
I have zero idea how to import things now so that they will work, because from what I can tell -every- single time I use a date in a formula, it skews the time another 6 hours.
If you are the only user in the workspace, you shouldn’t need to overthink date-time fields. On the UI (and when importing) Fibery will treat them as local time, so just forget about UTC.
Yes, it converts the date-time you provide into a date in UTC which it stores in the backend, but when you’re looking at data on the UI, it converts the data stored in the backend back into local time.
The problem comes with formulas that result in numbers or strings instead of date-time. These will always be based on the backend, since Fibery is designed as a multi-user platform, and it cannot always be guaranteed that all users are in the same timezone.
See this reply.
This is functionally 3 problems for me. I originally imported my datasets in UTC, so my initial imports are 6 hours skewed. Then in that dataset, I use a formula to create DateRanges – which recalculates skews the times. Then in another dataset, I use a formula to extract the relevant Dates of each in the DateRange – which recalculates and skews the times.
By the time I’m comparing one dataset to another, the original time is 18 hours changed.
Improvement
Fixed bugs
