SLA added automatically even though no SLA defined

[roshanroche]

Hi @tomolimo , i installed timezone plugin on glpi 9.2.4 by following ur wiki. it installed without any error and activated, i created users under 2 different entities with different timezone. since activation , when i create a ticket the SLAs added for both time to own and time to resolve ( both SLA and OLA ) as 19-01-2038 07:14 for all the tickets created. for all the tickets same time it shows

System Info : Centos 7.5 MariaDB 10.2.15 , tried both on glpi 9.1.7 and 9.2.4 same issue something related to database?

[tomolimo]

Hello @roshanroche Did you set the timezone for the server? Thank you Regards, Tomolimo

[roshanroche]

hi @tomolimo , i followed the steps from ur wiki. where on server i have to set the timezone? u mean php.ini? or is there any parameter in mariadb to do that?

[tomolimo]

Yes, it's in the php.ini

[tomolimo]

it's described in the wiki here: https://github.com/tomolimo/timezones/wiki/Requirements

[roshanroche]

yea i have done that. on php.ini.

[tomolimo]

good, then if you check the phpinfo(), you may get something like following in the timezone section:

date

date/time support enabled
"Olson" Timezone Database Version 2015.3
Timezone Database external
Default timezone Europe/Paris

could you paste this info here?

[roshanroche]

date/time support	enabled
timelib version	2017.06
"Olson" Timezone Database Version	0.system
Timezone Database	internal
Default timezone	Europe/Paris

[tomolimo]

Hello @roshanroche I made a test on my 9.2.4 and I got no problem:

this user in Europe/Paris TZ

and

this user in America/Detroit TZ

Could you provide me the complete step list to be able to reproduce your issue? Do you have any other plugins that would set these fields?

Thank you, Regards, Tomolimo

[roshanroche]

Hi @tomolimo , is this issue related to Mariadb 10 version? or is it related to something with this https://fossbytes.com/year-2038-problem-linux-unix/ it is happening on 9.1.7 version also. because i feel i have followed every step which u have mentioned in ur wiki. and it shows me the tz properly for users. it a fresh install of 9.2.4 without any plugins.

i found this error in sql SQL: INSERT INTO glpi_plugin_timezones_tasks_localtimes SELECT NULL, 'ChangeTask' as items_type, id as items_id, begin, end FROM glpi_changetasks; Error: Column count doesn't match value count at row 1 Backtrace : plugins/timezones/hook.php:178
plugins/timezones/hook.php:81 convertDB() inc/plugin.class.php:731 plugin_timezones_install() front/plugin.form.php:48 Plugin->install()

[roshanroche]

Hi , i also found under glpi_users table following entries

and under glpi_tickets table this

[tomolimo]

thank you for your investigations, could you also check the structure of the glpi_users and glpi_tickets tables? Especially the fields date fields? The type should be TIMESTAMP.

Could it be linked to the way MariaDB manages DATETIME field conversion to TIMESTAMP field?

[roshanroche]

[tomolimo]

Thank you,

I'll make a test using MariaDB, and I'll keep you informed,

Thank you, Regards, Tomolimo

[roshanroche]

@tomolimo , i see the default value for these fields is is that something related? i recall last time i had installed this plugin on 9.1.6 with maria db 5.4 version. i dont remember if i faced same issue or i noticed. this time around this installation was on MD 10 version.

[tomolimo]

Yes this default value is the MAX date that can be used in a TIMESTAMP field. But I don't understand why this default value has been set...

[roshanroche]

@tomolimo , thanks for ur time and patience. if i come across any related information ill inform u at the same time.

[roshanroche]

@tomolimo , funny thing is i resigned both tables and reset default value of the fields to NULL , and the SLA issue doesnt happen.

[tomolimo]

Hello @roshanroche I'm closing this issue as it seems tha tit was related to MariaDB default value for timestamp fields. Thank you Regards, Tomolimo