The LOCALES plugin creates the LOCALES table in the INFORMATION_SCHEMA database. The plugin also adds the SHOW LOCALES statement.The table and statement can be queried to see all locales that are compiled into the server.

Installing the Plugin

Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing INSTALL SONAME or . For example:

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an . For example:

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or . For example:

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Example

Options

locales

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

_{This page is licensed: CC BY-SA / Gnu FDL}

UTC stands for Coordinated Universal Time. It is the world standard for regulating time.

MariaDB stores values internally in UTC, converting them to the required time zone as required.

In general terms it is equivalent to Greenwich Mean Time (GMT), but UTC is used in technical contexts, as it is precisely defined at the subsecond level.

Time zones are offset relative to UTC. For example, time in Tonga is UTC + 13, so 03h00 UTC is 16h00 in Tonga.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

MariaDB server error messages are by default in English. However, MariaDB server also supports error message localization in many different languages. Each supported language has its own version of the error message file called errmsg.sys in a dedicated directory for that language.

Supported Languages for Error Messages

Error message localization is supported for the following languages:

• Bulgarian

• Chinese (from , , , , )

• Czech

• Danish

• Dutch

• English

• Estonian

• French

• Georgian (from )

• German

• Greek

• Hindi

• Hungarian

• Italian

• Japanese

• Korean

• Norwegian

• Norwegian-ny (Nynorsk)

• Polish

• Portuguese

• Romanian

• Russian

• Serbian

• Slovak

• Spanish

• Swahili (from )

• Swedish

• Ukrainian

Setting the lc_messages and lc_messages_dir System Variables

The and system variables can be used to set the used for error messages.

The system variable can be specified as a name. The language of the associated will be used for error messages. See for a list of supported locales and their associated languages.

The system variable is set to en_US by default, which means that error messages are in English by default.

If the system variable is set to a valid name, but the server can't find an for the language associated with the , then the default language will be used instead.

This system variable can be specified as command-line arguments to or it can be specified in a relevant server in an . For example:

The system variable can also be changed dynamically with . For example:

If a server has the system variable set to the fr_CA locale like the above example, then error messages would be in French. For example:

The system variable can be specified either as the path to the directory storing the server's or as the path to the directory storing the specific language's .

The server initially tries to interpret the value of the system variable as a path to the directory storing the server's . Therefore, it constructs the path to the language's by concatenating the value of the system variable with the language name of the specified by the system variable .

If the server does not find the for the language, then it tries to interpret the value of the system variable as a direct path to the directory storing the specific language's .

This system variable can be specified as command-line arguments to or it can be specified in a relevant server in an .

For example, to specify the path to the directory storing the server's :

Or to specify the path to the directory storing the specific language's :

The system variable can not be changed dynamically.

Setting the --language Option

The option can also be used to set the server's language for error messages, but it is deprecated. It is recommended to set the system variable instead.

The option can be specified either as a language name or as the path to the directory storing the language's . See for a list of supported locales and their associated languages.

This option can be specified as command-line arguments to or it can be specified in a relevant server in an .

For example, to specify a language name:

Or to specify the path to the directory storing the language's :

Character Set

The character set that the error messages are returned in is determined by the variable, which defaults to UTF8.

_{This page is licensed: CC BY-SA / Gnu FDL}

MariaDB keeps track of several time zone settings.

Setting the Time Zone

The time_zone system variable is the primary way to set the time zone. It can be specified in one of the following formats:

• The default value is SYSTEM, which indicates that the system time zone defined in the system variable will be used. Note that if you are using SYSTEM with replication in either statement or mixed mode, you MUST use the same value for system_time_zone on all replicas (otherwise TIMESTAMP columns will not replicate correctly). See below for more information.

• An offset from , such as +5:00 or -9:00, can also be used.

• If the time zone tables in the database were loaded, then a named time zone, such as America/New_York, Africa/Johannesburg, or Europe/Helsinki, is also permissible. See below for more information.

There are two time zone settings that can be set within MariaDB--the global server time zone, and the time zone for your current session. There is also a third time zone setting which may be relevant--the system time zone.

Global Server Time Zone

The global server time zone can be changed at server startup by setting the --default-time-zone option either on the command-line or in a server in an . For example:

The global server time zone can also be changed dynamically by setting the system variable as a user account that has the privilege. For example:

The current global server time zone can be viewed by looking at the global value of the system variable. For example:

Session Time Zone

Each session that connects to the server will also have its own time zone. This time zone is initially inherited from the global value of the system variable, which sets the session value of the same variable.

A session's time zone can be changed dynamically by setting the system variable. For example:

The current session time zone can be viewed by looking at the session value of the system variable. For example:

System Time Zone

The system time zone is determined when the server starts, and it sets the value of the system variable. The system time zone is usually read from the operating system's environment. You can change the system time zone in several different ways, such as:

• If you are starting the server with , then you can set the system time zone with the --timezone option either on the command-line or in the [mariadbd-safe] in an . For example:

• If you are using a Unix-like operating system, then you can set the system time zone by setting the TZ in your shell before starting the server. For example:

• On some Linux operating systems, you can change the default time zone for the whole system by making the symbolic link point to the desired time zone. For example:

• On some Debian-based Linux operating systems, you can change the default time zone for the whole system by executing the following:

• On Linux operating systems that use , you can change the default time zone for the whole system by using the utility. For example:

Time Zone Effects

Time Zone Effects on Functions

Some functions are affected by the time zone settings. These include:

Some functions are not affected. These include:

Time Zone Effects on Data Types

Some data types are affected by the time zone settings.

• - See for information on how this data type is affected by time zones.

• - See for information on how this data type is affected by time zones.

mysql Time Zone Tables

The database contains a number of time zone tables:

By default, these time zone tables in the database are created, but not populated.

If you are using a Unix-like operating system, then you can populate these tables using the utility, which uses the data available on Linux, Mac OS X, FreeBSD and Solaris.

If you are using Windows, then you will need to import pre-populated time zone tables. These are available at .

Time zone data needs to be updated on occasion. When that happens, the time zone tables may need to be reloaded.

See Also

• (video)

_{This page is licensed: CC BY-SA / Gnu FDL}

The lc_time_names server system variable sets the language used by the date and time functions DAYNAME(), MONTHNAME(), and DATE_FORMAT(), and the lc_messages sets the language for error messages.

The list of the locales supported by the current MariaDB installation can be obtained via the LOCALES plugin.

MariaDB supports the following locale values:

Examples

Setting the and variables to localize the units of date and time, and the server error messages.

_{This page is licensed: CC BY-SA / Gnu FDL}