I saw this Twitter post about the (potentially new) settings in Fibery
Those are really important for our clients! Plus the option to choose between comma and fullstop for number formatting. We import all financial data and it looks really odd for Dutch customers that comma is used
Iām also really curious about a potential scope for the Timezone when thatās a setting in the future.
One of the biggest problems weāre currently facing is that we donāt know what the specific date is of a date time field. Since formulas use UTC and when team members have different timezones, the appointments may not be linked correctly to the correct day/week/month plan.
Since formulas are not aware of timezones, I donāt think that this can be fixed. But really curious if we have a setting in the future what the possibilities would be with this new setting
This isnāt a Fibery problem, this is a real-world problem.
If I ask you what date a particular date-time falls on, the answer depends upon your timezone.
22/01/2024 04:00 UTC = the 22nd January in Europe but = the 21st January in the US, so a workspace with users in different continents cannot give the correct answer, because there is no correct answer.
What is the ideal solution? Define a workspace-wide timezone, or allow users to see different data?
If I ask a colleague whether the task was completed āthis weekā, they might say āyesā, but if they finished it at 11:30pm (local time) on Sunday night in San Francisco, I would say the answer is ānoā.
Agree, thatās our biggest problem since we canāt create a good workaround because of this.
For a Fibery workspace I think a workspace-wide timezone for automations + formulas is the best you can get. So you donāt need to create a bunch of extra formula fields for the date of a date time field and you will have more clarity for āon scheduleā automations.
Further, I think it can also be helpful to have a user specific time zone setting for users that
open the workspace in a different country (letās say a workation in Bali) but want to see all times as if they where in their normal country (currently youāll see your appointments at 22:30 and thatās a bit strange).
or use VPN, private browsers and stuff like that.
I think that the current setup in Fibery is already good (user sees the date/time based on their current timezone). But it would be more user-friendly if you can hoover over a field (or something similar) to see the timezone of that field. So you can debug the original time if needed.
I agree I was in particular interested in the possibilities that would occur if we have a timezone setting. Since itās a complex situation and I really donāt know what scope you guys have in mind.
Adapt date & time for each person individually
Rather than assuming a company-wide standard, we acknowledge that even teammates might have different preferences, so we format date and time per user across Fibery.
Be clear and unambiguous
When displaying time, we always specify the time zone. When itās the usual one, the indicator is unobtrusive (e.g. on hover); when the time zone differs from the userās, itās immediately clear (e.g. icon displayed).
Mind the diverse world
We allow the week to start on any day, not just Monday or Sunday, and display all options as equal.
Make the best effort to guess the right settings for each person
Rather than assuming everyone in the US and expecting everyone else to visit settings, we set the defaults based on the userās browser locale.
Assume some guesses will be wrong and allow for tweaks
Sometimes people have weird browser locales, and sometimes they use a different preferred time zone for work-related stuff ā thatās why we allow to override the settings.
The first day of the week is coming soon, the rest is less clear. Formatting date & time per user has the highest chances to be next (:
If you can achieve this, youāll have a top notch solution for timezone problem!
The set workspace time zone for user-independent services would be a real game changer. Since we can then simplify a lot of databases, delete the extra āsystem date fieldsā that weāve created and delete our current time zone workaround (we autolink everything to a timezone database to calculate the correct date).
Related to Format date and time (per User across all Fields)
Ideally we want to use one date field for date ranges
But currently we use two datefields when there is an optional end date. Else it looks a bit intense when you mostly have one date
Would be great if end date can be optional. Or if you keep it like it is but just donāt show the end date if start date = end date.
(or show text like āno end dateā, thatās also possible)
Even more ideal is that there is always just one date field and everything is optional within that field
User can set end date or leave it empty
User can set (start / end) time or leave it empty
Depending on the field value, you show or donāt show information in views
For our appointments (manually created or via Google Calendar integration) we currently have three fields
Date time field for appointments with time
Date field for all day events
It makes it really messy for a client since they currently see this
I feel these settings are a bit wasted away, with the current calendar UX (which is not great)
Iād rather have the wrong date formats, but an improved caledar to be honest.
Edit: I didnāt mean for this post to sound harsh!
@Matt_Blais yes thatās the problem We need to extract the date of a date time field for a lot of automations and formulas. And we canāt rely on the date time field because itās in UTC.
So currently we autolink every entity with date time field to our own ātime zone databaseā and use the offset to calculate the actual time and thus the correct date in formulasā¦
If all formulas use the āworkspace time zoneā then that solution would be needed anymore.
That would also be awesome. But I can use other tools for that as well
In my workspace I have āoverview pagesā for day, week, month, quarter and year.
I link applicable tasks, projects and meetings to those pages so you have one overview. Therefor I need the date of the meeting, which can be hard when you have a date time field.
We need to extract the date of a date time field for a lot of automations and formulas. And we canāt rely on the date time field because itās in UTC.