update otobo 10.1.4 to 10.1.5 timezone error

[A. Flora]

hi,

I run otobo docker and want to update otobo to version 10.1.5 but receive following error doing so:

ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.36.0 OS: linux Time: Wed Dec 14 13:36:09 2022

Message: Setting UserDefaultTimeZone Effective value is not correct: Europe/Amsterdam is not valid time zone!

 

This error is shown in the update steps:

# complete the update, with running database
docker_admin> docker-compose exec web /opt/otobo_install/entrypoint.sh do_update_tasks

# inspect the update log
docker_admin> docker-compose exec web cat /opt/otobo/var/log/update.log

 

when checking the update.log the error is shown in the log and the update fails.

If i try to connect with my internet browser i get a „Internal Server Error“ in my browser

How must i continue to get past this error ? I created a snapshot before doing the update so i am running now on my previous version 10.1.4

 

[bes]

Hi Flora,

this is an interesting case. On the code side everything is fairly simple. During the update the sanity of settings is checked. For UserDefaultTimeZone it is checked whether the value is a valid time zone. The list of time zones is taken from https://metacpan.org/pod/DateTime::TimeZone#DateTime::TimeZone-%3Eall_names . The method lists all canonical time zone names. Calling the method shows that Europe/Amsterdam is indeed not in the list.

perl -MDateTime::TimeZone -MData::Dx -E 'Dx DateTime::TimeZone->all_names' 2>&1 | grep Europe | head
"Europe/Andorra",
"Europe/Astrakhan",
"Europe/Athens",
"Europe/Belgrade",
"Europe/Berlin",
"Europe/Brussels",
"Europe/Bucharest",
"Europe/Budapest",
"Europe/Chisinau",
"Europe/Dublin",

Checking the time zone in Wikipedia, https://en.wikipedia.org/wiki/List_of_tz_database_time_zones . There Europe/Amsterdam is marked as Link† which indicates that the name is obsolete but used to be a canonical name.

According to https://data.iana.org/time-zones/tzdb/NEWS this change is fairly new, that is from 2022-08-10. The other affected time zones are:

Changes to past timestamps

Finish moving to 'backzone' the location-based zones whose
timestamps since 1970 are duplicates; adjust links accordingly.
This change ordinarily affects only pre-1970 timestamps, and with
the new PACKRATLIST option it does not affect any timestamps.
In this round the affected zones are Antarctica/Vostok,
Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik,
Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg,
Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas,
Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion,
Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei,
Pacific/Wake and Pacific/Wallis, and the affected links are
Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape,
Pacific/Truk, and Pacific/Yap.

A quick fix for your upgrade would be to change Europe/Amsterdam to Europe/Brussels before doing the update.

We will think about this could be automated during the update.

[A. Flora]

Sorry for my very late response but is it sufficient to change the parameter OTOBOTimeZone to the time of Europe/Brussels ?

It is now in UTC or must i make the change somewhere else ??

I also noticed that 10.1.6 is out, is the change in place in this update as you mentioned in your answer ?

[A. Flora]

Ok, i did change the parameter UserDefaultTimeZone to Europe/Brussels before upgrading directly to version 1.6 using the admin section and upgrade now worked, at least directly to version 1.6 . So that path is taken down

I noticed after succesfull upgrade and logging in that a message appeared that i needed to change my timezone from my user account, so this also worked.

Is it possible however to change the timezone for all created users so i can bulk update this setting ?

 

[bes]

Hi Flora,

sorry, the issue with the obsolete timezones has been put on hold, as everybody here is busy.

I also haven’t found an OTOBO console command that does batch update of user preferences. That would be an useful addition, but it hasn’t been tackled yet. Maybe another user on the forum has such a script lying about. Creating a script that fixes the Europe/Amsterdam problem would be fairly simple using Kernel::System::User. The modules provides methods for getting a list of agents, for getting the value of a preference, and setting the value for a preference.

Best regards,

Bernhard

 

 

[Author]

Posts