The .odt template file contains several links to the fields, text work correctly, the field eventually has a serious error: the time is displayed in the same way as it is stored in postgresql: in UTC format instead of UTC + 7. The site of the developer of this module prompted the idea that it is possible to add these 7 hours in the template itself, specifying it in a directive like

(o.visitdt) + relativedelta(hours=7)

but of course it doesn't work that way. What should be the syntax to perform like this? Or do you need to do something else to display the time correctly?

Thank you in advance.

  • In general, I can not imagine what odoo. Field in the database of what type? If timestamp with timezone, then it can be trite for the timezone user to change the base and the base will convert all timestamps by itself. - Shallow
  • Type field timestamp without timezone. - Scraggesh
  • without timezone reads exactly what was previously written. So the base will not help here. - Small

1 answer 1

The lack of information on valid commands for the aeroo reports' template directives led to a lot of blind searching. On the developer wiki there is a mention of temporary functions that are supported in the module:

Time related functions

dec_to_time - converts time to hh: min representation;

time - time access and conversions;

Among the temporary functions there is a command that in theory should solve my problem - tzset () , but I could not use it because the template did not accept the attempt to set the time zone. It is quite possible that I was doing something wrong, but I decided to find another way to solve the problem.

Here he is. The method is terrible, but until I think of anything better, it will come down.

I split the datetime into three parts:

 time.strftime("%d.%m.%Y", time.strptime(str(o.visitdt), "%Y-%m-%d %H:%M:%S"))

this is a date , everything is fine

 (time.strptime(str(o.visitdt), "%Y-%m-%d %H:%M:%S"))[3]+07

This clock is increased by 7 (my time zone)

 time.strftime("%M", time.strptime(str(o.visitdt), "%Y-%m-%d %H:%M:%S"))

the last part is minutes (no change).

As a result, we get exactly what we wanted (10/19/2017 11:00 for example).

Obviously, the system will fail if the original time is less than 7 am, but since the earliest time that can be available for recording is 8 am, the workaround will be fine.