Enabling GLPI timezone support for a multi-country service desk
Tickets, SLA clocks and asset dates in a multi-country GLPI instance are only as accurate as the way the database stores them. To get correct local times, you convert GLPI's datetime fields to timestamps with the glpi:migration:timestamps console command, then grant MySQL timezone access with db:enable_timezones. The conversion changes how stored values are read back, so it is a data change that needs a rehearsal on a copy of production before anyone runs it on the live database. The GLPI CLI documentation, linked below, lists the console commands and their options for your GLPI version.
Where this fits: timezone support is a post-upgrade or pre-upgrade hardening step, not a feature you switch on in the interface. Teams usually run it after the GLPI 10 to 11 move is stable, because the migration touches tables that plugins and the core both read. Assign ownership before the work starts. The database administrator owns the MySQL timezone tables and the grants, the GLPI administrator owns the console run and the post-run checks, and the service desk lead owns the test cases that compare ticket and SLA times against known local times in each country. Confirm with your database team whether the MySQL server's timezone data is loaded and who has the privilege to grant it.
Ask your implementation partner for the sequence in writing: a backup of the database and the glpi.key and glpicrypt.key files, a dry run on a restored copy, a list of plugins that store their own datetime columns, and a rollback plan with a tested restore. Confirm the exact command options and any version-specific prerequisites against the GLPI CLI documentation for the version you run, since behavior can differ between releases.
What changes in the database and in the console
This table compares the database column type, the console commands and the display behavior before and after the timezone migration. Read each row as a check to run on a copy of your database first, because the conversion changes stored values and not just how they are shown.
| Change | What it does | Action needed |
|---|---|---|
| Datetime columns to timestamp | The glpi:migration:timestamps command converts datetime fields to timestamp so GLPI can store values in a timezone-aware form. | Run the command on a tested copy first and record row counts and timing before touching production. |
| Timezone grant on MySQL | The db:enable_timezones console command prepares the database so MySQL timezone data can be used by GLPI. | Confirm with the GLPI CLI documentation for your target version which privileges and timezone tables must be loaded. |
| Stored values | Timestamp columns store values in UTC and convert on read, while datetime columns store the literal value with no zone attached. | Verify a sample of ticket and log timestamps before and after the change so you know what the stored data now means. |
| Display per user | Once the conversion and grant are in place, times can be shown in each user's configured timezone instead of one server-wide value. | Set user and entity timezones deliberately and test with users in at least two countries. |
| Scripts and reports | Exports, custom SQL, reports and integrations that read raw columns may see different values or formats after conversion. | Inventory every query and external consumer that reads these columns and retest them. |
| Plugins with their own date columns | Plugin tables that use datetime fields are not guaranteed to be converted by the core command. | Check each plugin's documentation and compatibility with the target GLPI version before the migration. |
| Rollback | Reversing the conversion is not a simple toggle, so the database backup taken before the run is the recovery path. | Take and verify a full database backup, and confirm the restore procedure before the window opens. |
| Exact command behavior | Options, prompts, order and any required flags can differ between GLPI versions. | Confirm the exact behavior against the GLPI CLI documentation for the target version before running anything. |
What to prepare before touching the timestamp columns
The timestamp conversion rewrites every datetime column the migration touches, so recovery and testing have to be in place first. The six preparation steps below cover recovery, a rehearsal environment, the database server, downstream readers and the test matrix.
Verified backup of data and keys
Take a database dump, a copy of the GLPI files and a copy of the config directory, including glpi.key and glpicrypt.key. Losing the key files can make encrypted values unreadable after a restore, so copy them separately and store them with the rest of the backup. Restore the backup to a scratch host and confirm that GLPI logs in and shows tickets with the expected dates before you rely on it.
Rehearsal copy of production
Restore a recent production database into a separate environment and run the timestamp migration there first. Record how long the run takes on that copy, how many tables it changes and any errors it raises. The rehearsal result sets the maintenance window you can ask your team to approve, so compare it with a production-sized copy rather than a small test database.
Database server and timezone data
Confirm the MySQL or MariaDB version against the GLPI prerequisites for your release, then check that the server has timezone tables loaded. Without them, conversions from local time to UTC cannot be computed. Ask your database administrator who will grant GLPI's account access to the timezone tables, since this is a separate privilege from normal application access.
Inventory of readers and writers
List every custom report, dashboard query, external integration, webhook, plugin and script that reads or writes datetime columns in the GLPI database. Each one may assume local time or a specific format and will need a review after conversion. Note the owner of each item so that someone can test it and sign off during the rehearsal.
Plugin compatibility check
Confirm which installed plugins read GLPI datetime fields directly and whether their vendors support the timestamp change. Plugins are suspended after a new version is detected, so keep a record of which ones must be reactivated or replaced. Treat any plugin without a clear answer as a blocker for the rehearsal until its behavior is confirmed.
Countries and timezone test matrix
Write down the countries, sites and user timezone settings your service desk uses, then pick a test user for each. For each test user, create a ticket and a reminder, then check the displayed times against a known clock. Include users near daylight saving transitions, because those are where conversion errors usually appear.
Running the timestamp migration in order
This sequence converts GLPI datetime columns to timestamps and grants MySQL timezone access on a rehearsal copy first, so the production run follows a path the team has already checked. Each step ends with a verifiable result and a point to return to if something goes wrong.
Take full backups before any change
Before touching the database, the GLPI administrator takes a backup of the database, the GLPI files and the config directory, including the glpi.key and glpicrypt.key files. Store the backup somewhere separate from the server, and record the GLPI version and database engine in the change ticket. This backup is the first rollback point: if the rehearsal or production run fails, restoring it returns the instance to its prior state. The step is done when a restore of the database dump has been listed or tested without errors.
Restore the backup to a rehearsal copy
The platform team restores the database, files and config directory to a separate host or container that matches production as closely as possible, including PHP version, database server and web server layout. The rehearsal copy must not send notifications to real users or call live integrations, so disable outbound mail and connectors before first login. The step is complete when the copy starts, users can sign in, and the ticket counts and asset counts match the source backup.
Grant MySQL timezone access with the console command
On the rehearsal copy, the administrator runs the GLPI console command for timezone support, db:enable_timezones, which prepares the database so GLPI can read and apply timezone data. Check the exact syntax for your GLPI version in the GLPI command-line interface documentation before running it, because the command and its options can change between releases. Then confirm in the database that the timezone tables are populated, since a missing grant shows up later as wrong or empty local times. The step is done when the command completes without errors and the check query returns named timezones.
Run the timestamp migration command
The administrator runs glpi:migration:timestamps on the rehearsal copy to convert datetime fields to timestamp columns, which lets GLPI store values in UTC and display them in each user's timezone. Run it with the same console user and PHP version that production will use, and capture the full output in the change record. Expect the run to take longer on large databases, so watch for locked tables and monitor disk space during the conversion. The step is done when the command reports completion and the logs contain no unresolved errors.
Confirm the converted data on the rehearsal copy
The team checks the rehearsal copy against the source: row counts for tickets, assets, and logs, sample ticket open and close times, scheduled tasks, and reports that filter by date. They sign in as users in at least two timezones and confirm that the same ticket shows the expected local time in each. Record any differences and rerun the rehearsal from the backup until they are resolved, because the production run should not be the first time the migration is tested. The step is done when the checks are signed off in writing by the service desk owner.
Repeat the migration on production in a maintenance window
During an agreed maintenance window, the team puts GLPI into maintenance or blocks user logins, takes a fresh backup of production, and runs the same commands in the same order used on the rehearsal copy. Stop if any command output differs from the rehearsal, and use the fresh backup as the rollback point. Restoring it returns production to the pre-migration state if verification fails. The step is done when the migration completes and the production checks match the signed-off rehearsal results.
Verify production and close the change
After production returns to service, the team repeats the sample checks from the rehearsal in at least two timezones, reviews scheduled tasks and notification queues, and monitors error logs for an agreed observation period. They confirm that existing dates in reports and exports still make sense to the business. Keep the pre-migration backup until the team accepts the result, then close the change record with the command output and check results attached. The step is done when the service desk owner accepts production in writing.
Why datetime columns and the MySQL timezone grant both matter
GLPI stores many of its dates in datetime columns, and a datetime value carries no timezone information of its own. The database stores the wall-clock reading and returns it unchanged, so a ticket opened at 09:00 in one country and read in another can show the same clock figure with no conversion applied. Converting the relevant fields to timestamp columns is what lets the database interpret those values against a timezone and return them in the viewer's local time. That is the reason the timestamp conversion is a precondition for timezone display, not a cosmetic change. Before you run it, confirm with your team which GLPI fields are affected and whether any reports, integrations or exports read those columns directly, because their output will change once values are converted.
The conversion also depends on the database server knowing its timezone tables. MySQL and MariaDB convert timestamps through timezone data that is loaded separately from the server itself, and if that data is missing, the conversion can produce unexpected results or fail. The database account GLPI uses must also be able to read that timezone data, which is why the grant matters. Ask your database administrator to confirm that the timezone tables are populated on the server, that the GLPI account holds the privilege to read them, and that the server's own timezone setting is what you expect. Check these on a copy of the database first, since a missing grant is easier to fix before a production migration than during one.
Plan the sequence deliberately. Confirm the server setup, take a verified backup, run the migration on a restored copy, and then check how times display for users in each country your service desk serves. Record the server timezone, the GLPI user timezone settings and a sample of tickets with known creation times so the before and after results can be compared. Ask your GLPI partner or internal team to document which console commands ran, in what order, and which account executed them, because this becomes the audit trail for a change that touches every dated record in the instance.
What makes a timezone migration take longer
This table lists the factors that change how much work a timestamp conversion involves and how to size each one before scheduling. Read it as a scoping checklist: the rows that score highest on your instance are the ones to resolve with your team before you agree a window.
| Effort driver | Why it matters | How to scope it |
|---|---|---|
| Database size and datetime column count | The migration converts datetime fields to timestamp across the schema, so more tables and rows mean more time spent rewriting data while the instance is unavailable. | Count datetime columns and row totals per table on a copy of the database, then confirm the window with those numbers in hand. |
| Custom reports and dashboards | Saved searches, reports and dashboards that read or filter on times may return different results once values are stored as timestamps and displayed in user timezones. | Inventory every custom report, dashboard and saved search that uses date filters, and list the owner who will check each one afterward. |
| Plugins and integrations that read or write datetimes | Plugins, inventory imports, webhooks and API clients that send or expect datetime values can break or store shifted times if they assume server-local time. | List each plugin and integration that touches dates, confirm its compatibility with the migration, and test one write and one read on the copy. |
| Number of countries and timezone rules | Each country or site may apply different offsets and daylight saving transitions, so more locations mean more cases to verify before users rely on the times. | Pick representative sites for each timezone, record expected local times for sample tickets, and check them against the migrated copy. |
| Entities and user timezone settings | Users who have not set a personal timezone inherit defaults, so the number of profiles and entities with differing settings affects how many configurations need review. | Ask which entities and user groups need their own timezone and confirm who owns those settings after go-live. |
| Rehearsal copy availability | Without a restored copy of production, the first real test happens on live data, which raises the risk of a failed conversion during business hours. | Confirm that a recent backup can be restored to a separate server with the same GLPI version and plugin set before scheduling. |
| Maintenance window availability | The conversion needs a period when no tickets, imports or automatic actions are writing to the database, so a narrow or unconfirmed window extends the schedule. | Agree the window with service desk managers and confirm that automatic actions and inventory jobs can be paused for its duration. |
| Recovery plan and backups | A failed conversion that cannot be reversed from a verified backup turns a planned change into an incident, and that recovery work adds effort. | Verify the backup set, document the restore steps, and record who approves a rollback decision before the window opens. |
How the approach differs by deployment model
On a Linux server install, the console runs from the GLPI installation directory on the same host that serves the web application. The commands read the same config directory and database settings the web server uses, so the account running them matters. Run them as the account that owns the GLPI files, or as the web server user, so file permissions stay intact. Plan a maintenance window, because the migration changes column types on tables the application reads and writes.
- Console location: run
php bin/consolefrom the GLPI root using the same PHP version the web server uses. - Database account: the GLPI database user must be able to alter tables. Confirm whether your database owner grants that temporarily or keeps a separate migration account.
- Timezone tables: MySQL and MariaDB load timezone data separately from the server. Confirm the server has it populated before you enable timezone support.
- Backups first: back up the database, the files and the
configdirectory, includingglpi.keyandglpicrypt.key, before you change the schema. - Session impact: users may be signed out or see errors while tables are altered, so announce the window in advance.
Before scheduling, confirm with the database owner that the migration account can alter tables and that the timezone tables are loaded on the database server.
In a Docker install, GLPI and its web server run in a container, while the database usually runs in another container or on a separate host. Console commands must run inside the GLPI container, against the same configuration volume the application uses, so the migration reads the settings the running instance depends on. Anything written to the container filesystem is lost when the container is replaced, so configuration and files must persist on volumes.
- Exec into the container: run the console with
docker execor your orchestrator's equivalent. Confirm the working directory in the image you deploy. - Persistent keys: confirm
glpi.keyandglpicrypt.keysit on a persistent volume. Losing them after a rebuild can leave the instance unable to read its encrypted data. - Database network: the database host name in the configuration must resolve and accept connections from inside the GLPI container. Test the connection before the migration.
- Timezone data in the database container: the GLPI container does not supply timezone tables. Check the database container's data volume and server setup.
- Image version: pin the image tag to the version you are migrating to, so code and schema match. The GLPI 12.0.0 release notes list an official Docker image among the distribution options.
Ask the database owner whether the migration account is reachable from the GLPI container network and whether the timezone tables exist in the database container's data.
With a managed database service, you usually have no operating system access to the database host, and the provider controls some server settings. Timezone data and the ability to grant access to timezone tables may be restricted or handled through a support process. Console commands still run on the GLPI host, but they connect over the network with an account the provider issued, so the grant scope becomes a provider decision as well as your own.
- Provider-controlled settings: timezone tables may be loaded by the provider. Confirm the process, who performs it and how long it takes.
- Account privileges: managed services often restrict global grants. Confirm which privileges the GLPI account receives and whether it can alter GLPI tables.
- Maintenance and failover: check how provider maintenance windows and failover events affect a long schema change, and whether the migration can be paused safely.
- Replicas: if GLPI reads from a replica, confirm the migration runs against the primary and that replication carries the schema change to the replica.
- Restore point: confirm how the provider's snapshots work and whether you can restore to a point before the migration.
Get the provider's written confirmation of timezone table status, grant scope and restore options before you schedule the window.
Questions teams ask before timezone migration work
What does timezone migration work cost and which parts drive the effort?
Cost depends on the size of the GLPI instance, the number of plugins and custom reports that read datetime columns, and how many environments must be validated before production. The conversion itself runs through the console command glpi:migration:timestamps, so the command is rarely the expensive part. Effort grows with the testing you need: a copy of the production database, checks of ticket SLAs, planning and reporting views in several time zones, and a rehearsal of the maintenance window. Costs are one-time for the migration, with some recurring cost only if you later ask a partner to support the platform. Ask any partner for a fixed-scope quote that lists each environment, each test case and each integration checked.
How long does a GLPI timestamp migration usually take?
Duration depends less on the commands and more on the database size, the length of the agreed maintenance window and the number of test rounds. Large databases with many datetime columns need more time to convert and more time to verify, so the database size is the first thing to measure on a copy. Teams with several countries also need time to confirm that ticket dates, SLA deadlines and reports display correctly for users in each zone. No duration can be promised without a copy of your data and a written scope, so ask for a timeline tied to those inputs and to the agreed change window.
What must our internal team provide before the work starts?
Your team needs to provide four things before any production change:
- Database access for a copy of production, with a user that can run schema changes and read the results
- Agreed maintenance windows long enough to back up, convert and verify the instance
- Test users in each country or time zone your service desk serves, with known tickets to check
- A named owner who can approve results and decide whether a rollback is needed
Also confirm who holds the GLPI key files and backups, since a restore must be possible before the conversion starts.
Can our own team run the timezone commands without a partner?
Yes, a team with database and GLPI console experience can run the commands, provided it follows the GLPI documentation and tests on a copy first. The GLPI command-line documentation covers glpi:migration:timestamps and the db:enable_timezones command, which grants MySQL timezone access. The risk is less in typing the commands than in the steps around them: backup, verification of plugin behavior, and confirming that server, database and browser time zones agree. A partner can take over that work under a written scope if your team lacks time or experience. Decide this before the test cycle, not after a failed conversion.
What happens to plugins and custom reports after the conversion?
Plugins and custom reports that read or write datetime fields need to be checked after conversion, because their queries and display code may assume the old storage format. Some plugins may also be suspended by GLPI after a version change, so compatibility should be confirmed before the conversion window opens. Custom SQL reports, dashboards and exports deserve the same review, especially those that compare dates across time zones. Build an inventory of these items during planning, then test each one on the copy. Ask the GLPI plugin vendor or maintainer for their stated support for timestamp columns.
How do we request a fixed-scope quote for this work?
Send a written description of your GLPI version, database engine and size, server setup, plugins in use, custom reports, the countries and time zones served, and the maintenance windows you can offer. A fixed-scope quote should list the environments involved, the backup and rollback steps, the conversion and verification tasks, the test cases for each time zone, the handover documents and any post-change support. DeployOpen plans, implements and documents this kind of work in infrastructure you control and agrees scope, deliverables and timelines in writing before work starts. Ask for the quote to state what is excluded, such as plugin fixes or unrelated upgrades.
How DeployOpen scopes and delivers a GLPI timezone migration
DeployOpen treats enabling GLPI timezone support as a database change with console steps, not a settings toggle. We start from a written scope that names the instance, the database engine, the datetime columns in question and the countries and service desks that depend on correct times. The work is delivered in your infrastructure and documented so your team can repeat it.
How we scope
- The written scope names your GLPI version, database engine and the users and entities whose times must display correctly.
- We inventory the datetime columns and plugin tables that the timestamp conversion would touch, so nothing is discovered mid-change.
- Engagements are fixed-scope, with deliverables and timing agreed in writing before work starts, and a quote follows from that scope.
How we build
- We run the timestamp migration and the MySQL timezone setup on a copy of your production database first, then record the runtime results.
- We check the database timezone grant, the PHP timezone and the web server clock, then confirm times match across test sessions in each country.
- We review plugin tables and custom fields that hold datetime values, and agree with you how each one is handled before the production run.
How we hand over
- You receive a runbook listing each console command, its order, its expected output and the rollback steps if a run stops partway.
- The documentation records the database grants, the time zone configuration and the verification checks used to confirm correct times.
- Your team walks through a rehearsal run with us so the production change is performed or reviewed by staff who understand it.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so timezone settings can be rechecked after future GLPI updates.
- Before any GLPI major update, we can review whether the timestamp state and timezone grants still match the target version.
- Ask us to confirm in the quote who takes ownership of backups, restore tests and any post-change monitoring of GLPI logs.
