Skip to Content
Menú
This question has been flagged
1 Respondre
4255 Vistes

float_time widget does not account for logged in user timezone and that is the only thing I found that can represent Time field but without timezone support it's misleading and bad to use.


Datetime field has this support, read the following example:

For example if I logged in and I have timezone UTC+2 set in settings and I want to create a new record in the web form view on a model that has a Datetime field, if I would enter 

(any date) 08:00h this would get saved in the database as 06:00 because it is always converted to UTC-0 and when it is loaded back it also takes in the account user timezone, so for me it would be displayed as 08:00 even tho it is saved as 06:00


Now above example with Datetime works and is fine. Problem is that float_time DOES NOT take into account the timezone of user when saving. Below is eample with float_time:


class Example(models.Model):
   _name = "example.example"
   _rec_name = "work_time"

   work_time = fields.Float(string='Worktime start', required=True)


My form and tree views are as simple as possible (both have only one field which is work_time, form view is declared as widget="float_time").

If I would create new record with my user who has UTC+2 set as timezone and set work_time to 08:00 this would get saved as 08:00 in the database, without accounting the user timezone. Problem is if another user logs in, with different timezone for example UTC-1, he would still see that record as 08:00 , now think what would happened if both would come to a meeting at 08:00 - they would be 3h apart! For this other user instead of showing it as 08:00 it should show it as 05:00 !


Why is there no proper built in thing for Time field? The above example is one of the most basic things the framework (with major version 14) should support.


Is the only way to hack my own custom field for this?


Avatar
Descartar
Autor Best Answer

I realized not too long after writting this question that there is a flaw with time with timezone support.

You see since it's not tied to date in certain cases,if the timezone difference is big enough,it can happen that for some users time shows as negative (goes into previous day) or larger than 23 (goes into next day). This could be confusing to users and since time is not tied to date we can't normalize it.


So hacking it together would require this field to be tied to date, essentially could use datetime in that case.

Problem is that my form entries would be better and more inuitive if I have separate entry for date (day period) and separate entry for time (work time start/end). I already have a idea how to make the view I want with just using datetime and some compute fields.

Avatar
Descartar
Related Posts Respostes Vistes Activitat
0
d’abr. 21
4304
3
de juny 15
26775
0
d’abr. 15
4527
3
de jul. 25
3873
6
de set. 19
11163