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:
- 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).
- 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:
- Allow calendars to have all the types of date fields presented in the same calendar.
- 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)
- Add a flexible field that allows to chande the scheduling mode of a date field from specific hour to an entire day.
- 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.