Twitter post about potentially new Fibery settings

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 :exploding_head:

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 :smile:

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 :smile: 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.

Here is how we think about date localization problems:

And here are the principles we’ll strive for:

  • 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 (:

2 Likes

You guys are awesome! :heart:

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

image

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.
image

(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

If you have one ‘date time range’ field where everything is possible, but also optional that would be insane :exploding_head:

Can imagine that it’s technically challenging or maybe not even possible, but it would be so much more user friendly :smile:

I feel these settings are a bit wasted away, with the current calendar UX (which is not great) :frowning:
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!

1 Like

This is what exists now - all dates are in UTC from the scripts/formulas point of view.

@Matt_Blais yes that’s the problem :sweat_smile: 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.

I guess this is because you want to email users with a reminder of for an upcoming event?

That would also be awesome. But I can use other tools for that as well :smile:

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.

1 Like