More Flexible Date FIeld

I wnat to start and say that overall this is not a “real” issue. By that I mean that I can more or less have all the functionality needed in the current version. What I am about to request is more a matter of convenience.
Currently, when defining a date field, the user must choose if he wants to specify an end date, or time (or both or none). I must say that this is not very convenient. And even more importantly, it does not really represent how assigning dates can behave in the real world. The simplest example is scheduling a task. I may want to schedule it to a specific date, which means that it needs to be done during that day, but there isn’t any specific hout in which it must be done. Or I may want to schedule it to a specific hour in a specific day.
Currenly, the only workarounds for this problem are ti either:

  1. Have 2 fields in the same task for each scheduling option. This is not preferable since it means that one of the fields is always going to be empty, which is kind of a waste.
  2. Seperate the scheduling finctionality from the task, into two seperate types, each for each type of scheduling. This is not a real option as currently inheritance of relations is not possible, so defining each type requires to much work, and makes related types have a ton of relationships.

I think a quick fix for that is adding another option for the date field definition that defines the field as being assigned a date or a date + time.

I think that this is the kind of featue that allows for simplicity on top of the increadible functionality in the app.

Just so I understand, are you saying that you’d like it to behave similarly to the Outlook calendar, for example, where there is a checkbox to distinguish an all-day task from one where the time of day is important?

However, it is important to note that I do not think that it should replace the way fields are defined right now, just this should be another option in addition to existing ones.

It is possible to add a button which when pressed will adjust the values of a datetime field to run from midnight to midnight. When such an entity is displayed on a calendar, it is shown as an all day event.


You could also have a checkbox field so that such events are easily identifiable/filterable when in other views (table, board, list etc.)

I relize it has been a while since the answer was given, but I’ve just tried the solution and ran into some problems.

First of all I think it would be best to first clarify what it is about the workaround that makes it sufficient:

  1. It allows to create a representation of the date field using the date time field (so that a date time field can also be used like a date field).
  2. The values selected for the date time field are not random. In other words, we choose specific values that represent the properties of a day as closely as possible.

Personally, I would choose the whole day event to be scheduled from 00:00 to 23:59 so it appears only in one day and not on 2 in the calendar, but thats only a personal preference. So, from now on I will assume that we use the 23:59 representation.

The reason why this workaround is problematic is the way it interacts with the way fibery handles timezones.

Time zones are handled at the UI level, and behind the scenes only the UTC time is saved.
This means that when a user in time zone GMT+2 saves the time 13:00, the app recognizes that the user operates in time zone GMT+2, and converts the time to 11:00 UTC and saves it that way. Later, when the user accesses the field, the app will again recognize the user time zone and know that when it presents the time to the user it should add 2 hours to the time it recieves from the server.

(A full explanation of how timezones work in fibery can be found here:
Timezones | Fibery Help Center)

As long as the user enters the time everything works just fine. However, when using formulas things get more complicated.

In formulas, formula functions (such as DateTimeRange) expect to recieve UTC time. This means that I should enter the time after conversion to the formula when changing the value of the time field.

This also would’nt be a problem unless we had to take into account Winter and Summer times. Twice a year countries chage their time zone. For example, I am currently in time zone GMT+3, yet during winter I am in time zone GMT+2.

So, why don’t just enter time for the formula according to the time of year (for example, enter 2 to the hour parameter when setting the date field value during winter and 3 during the summer)?

Well, the problem is that in many cases the time zone is not switched on the same date every year. For example, in europe, it is switch on the last sunday of october. So as long as I cannot create a condition of “if the time is between the last sunday of october this year and the last sunday of march next year” in a formula, it is impossible to use formulas to set an exact date.

And this is a problem. This is a problem, since it means that there will always be some dates every year that when I use the button the date part of the date time field will be set by the formula to a date different that the date intended.

For example, the entity might be schedled from 15:00-18:00 in October 6, yet after using the button the start time will have the date of October 5.

And if we go back to the conditions by which we measure if the workaround is sufficient, this violates condition (1), as we intended to schedule an event to October 6, yet it will appear on october 5 and october 6 (so it will apear in the calendar to be scheduled to 2 days instead of 1).

So, why don’t just choose a time which does not cause this kind of problem with the times zones?
The reason for that is that is violates condition (2)!
If I wanted to choose some random time during the day to schedule my “whole day event” to I could do this manually. But I don’t want a random time, I want a time that represent the essence of a whole day.

If there is a workaround to any of the promlems I mentioned, I would like to hear it, as I could not think of any.

But I think that the main takeaway from what I wrote should not be to search for a workaround, but that the feature I requested is actually really useful.

As a rule of thumb, I think that users should not have to search for how time zones work whenever they want to configure a date field, especially when they want to configure something as simple as what I have requested.

You should either allow for more date related functionality out of the box, or make formulas a usable alternative.

For me, to allow using the date field for anything other than the most basic things the following features must be implemented:

  1. Allow calendars to have all the types of date fields presented in the same calendar.
  2. Allow a calendar to present date fields with different names (why should I care what the name of the field is and start renaming fields just so that they can appear on the same calendar)
  3. Add a flexible field that allows to chande the scheduling mode of a date field from specific hour to an entire day.
  4. Fix the way formulas handle time zones, as it is practically unusable. There are many ways to change this, but it is clear that some sort of change must occur.
1 Like