MySQL Time Zone Support (with examples)

MySQL Time Zone Support

Time zone handling can sometimes generate confusion, especially when dealing with data migrations to a different host running on a different time zone, when switching to a Daylight Saving Time (DST) time zone or when leap seconds are introduced. Will the stored date still make sense after changing a system-wide configuration? What happens when you migrate a server to another host? What is actually stored in the database?

There’s plenty of literature around MySQL and time zone management, but there’s also missing information because new features and fixes are constantly introduced into MySQL Server in this area. So I thought that spending a few words here to summarize how to best deal with time zones, and keeping this information up to date to reflect the current implementation could be a good idea.

MySQL Globalization chapters document everything you need to know to deal with time zones and character sets.

MySQL time zone settings

First of all, let’s summarize what are the configuration parameters that affect the way MySQL works with time zones. It is possible to configure time zones using the following parameters.

  • –timezone This is to be used with mysqld_safe and sets TZ environment variable to the desired time zone.
  • system_time_zone This corresponds to the time zone inherited from OS configured TZ or what configured via mysqld_safe with –timezone.
  • time_zone This initializes the time zone for client connections, usually defaults to SYSTEM, thus inheriting same value as system_time_zone. If a different time zone setting is desired for a client, use this variable.
  • –default-time-zone command line modifier initializes time_zone to the desired default value.
  • log_timestamps It sets the time zone of timestamps in the messages written to the error log, general query log and slow query. Default values is UTC.

There is also another setting that is worth keeping in mind, and it’s the client’s current time, configurable using the timestamp variable. Not really related to time zone, but worth knowing. It sets the desired time for clients restoring from e.g. binary logs and including NOW() statement. So, it affects the value returned by NOW().

MySQL inherits OS time zone

One of the possible options to change MySQL system time zone is changing OS time zone. MySQL will inherit OS time zone to initialize @@system_time_zone at start time. Let’s review the commands to be used in Linux to read the current OS time zone settings.

Discover current time zone

bash-3.2$ date
Sab 3 Apr 2021 21:24:31 CEST
bash-3.2$ ls -l /etc/localtime
lrwxr-xr-x 1 root wheel 37 11 Feb 10:40 /etc/localtime -> /var/db/timezone/zoneinfo/Europe/Rome

Change time zone

sudo ln -sf /usr/share/zoneinfo/Africa/Nairobi /etc/localtime

List available time zones

ls /usr/share/zoneinfo
+VERSION Brazil EST5EDT GMT Indian MST Pacific US posixrules
Africa CET Egypt GMT+0 Iran MST7MDT Poland UTC zone.tab
America CST6CDT Eire GMT-0 Israel Mexico Portugal Universal
Antarctica Canada Etc GMT0 Jamaica NZ ROC W-SU
Arctic Chile Europe Greenwich Japan NZ-CHAT ROK WET
Asia Cuba Factory HST Kwajalein Navajo Singapore Zulu
Atlantic EET GB Hongkong Libya PRC Turkey iso3166.tab
Australia EST GB-Eire Iceland MET PST8PDT UCT leapseconds

Change MySQL system and client time zone

Instead of changing the OS time zone so it is loaded at MySQL start time (which in turn initializes @@system_time_zone), it is possible to set MySQL @@system_time_zone by either:

  • Setting TZ environment variable
  • Restarting the server using –timezone with mysqld_safe

Note that using either method will fail with the following error if zones are not imported into MySQL beforehand.

2021-04-03T19:38:53.620924Z 0 [ERROR] [MY-000067] [Server] unknown variable 'system_time_zone=EST'

Same outcome if attempting to set time_zone:

mysql> SET time_zone=EST;
ERROR 1298 (HY000): Unknown or incorrect time zone: 'EST'

Let’s then import time zones information into MySQL, taking advantage of mysql_tzinfo_to_sql.

bash-3.2$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -uroot - mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
Warning: Unable to load '/usr/share/zoneinfo/+VERSION' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leapseconds' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.

Warnings can be ignored, they are reported when the tool attempts to import miscellaneous not related files that are stored in the /usr/share/zoneinfo folder. Now that zone tables are loaded into MySQL, it is possible to verify them:

mysql> SELECT * FROM mysql.time_zone_name LIMIT 3;
+--------------------+--------------+
| Name               | Time_zone_id |
+--------------------+--------------+
| Africa/Abidjan     | 1            |
| Africa/Accra       | 2            |
| Africa/Addis_Ababa | 3            |
+--------------------+--------------+
3 rows in set (0.00 sec)

It is now possible to set the desired system time zone, by setting the corresponding environment variable (it will need a restart):

bash-3.2$ export TZ=EST

The alternate method to set the system time zone is using –timezone with mysqld_safe. After server restart, which now completes successfully, let’s check:

mysql> SELECT @@system_time_zone, @@time_zone;
+--------------------+-------------+
| @@system_time_zone | @@time_zone |
+--------------------+-------------+
| EST                | SYSTEM      |
+--------------------+-------------+
1 row in set (0.00 sec)

This option will avoid changing OS system time zone. The possible values for –timezone or TZ are system-dependent. Consult your operating system documentation to see what values are acceptable. Now the client can set the time_zone to an arbitrary desired time zone for the session:

mysql> SET time_zone=UTC;
Query OK, 0 rows affected (0.00 sec)

Server migrations

Let’s see what happens to stored data when the OS time zone changes (or the change is forced, as usual, by a change to TZ environment variable). Pay attention to the system_time_zone. If we insert a table:

CREATE TABLE mydate (
dt datetime DEFAULT NULL,
ts timestamp NULL DEFAULT NULL
) ENGINE=InnoDB;

With data:

INSERT INTO mydate(dt,ts) VALUES('2015-11-13 10:20:19', '2015-11-13 10:20:19');

And then we attempt to retrieve it, it’ll be correct until we remain on the same time zone settings.

mysql> SELECT @@system_time_zone, @@time_zone;
+--------------------+-------------+
| @@system_time_zone | @@time_zone |
+--------------------+-------------+
| EST                | SYSTEM      |
+--------------------+-------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM test.mydate;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2015-11-13 10:20:19 | 2015-11-13 10:20:19 |
+---------------------+---------------------+
1 row in set (0.03 sec)

But if we restart the server on a different time zone (e.g. a server using a different TZ environment variable).

mysql> SELECT @@system_time_zone, @@time_zone;
+--------------------+-------------+
| @@system_time_zone | @@time_zone |
+--------------------+-------------+
| CEST               | SYSTEM      |
+--------------------+-------------+
1 row in set (0.00 sec)

Then DATETIME will be preserved, but the TIMESTAMP will be interpreted using the different time_zone, inherited from system_time_zone. This is what differentiates DATETIME from TIMESTAMP: DATETIME is always read “as is”, whereas TIMESTAMP is calculated against the session time_zone.

mysql> SELECT * FROM mydate;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2015-11-13 10:20:19 | 2015-11-13 16:20:19 |
+---------------------+---------------------+
1 row in set (0.00 sec)

At this point it is possible to make the host time zone change not affect the results by setting:

mysql> SET time_zone='EST';
Query OK, 0 rows affected (0.02 sec)

mysql> SELECT @@system_time_zone, @@time_zone;
+--------------------+-------------+
| @@system_time_zone | @@time_zone |
+--------------------+-------------+
| CEST               | EST         |
+--------------------+-------------+
1 row in set (0.00 sec)

mysql> SELECT * from test.mydate;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2015-11-13 10:20:19 | 2015-11-13 10:20:19 |
+---------------------+---------------------+
1 row in set (0.00 sec)

Useful statements

You have seen, so far, what is the relation between the OS and MySQL for what concerns time zone settings. Before considering other examples, here are a few MySQL statements that may become handy.

Select a timestamp column in UTC format

SELECT
CONVERT_TZ(timestamp_field, @@session.time_zone, '+00:00') AS utc_datetime
FROM table_name

Select the current datetime in the session time zone

SELECT CURRENT_TIMESTAMP();
+---------------------+
| CURRENT_TIMESTAMP() |
+---------------------+
| 2021-04-03 21:58:10 |
+---------------------+
1 row in set (0.00 sec)
SELECT NOW();
+---------------------+
| NOW()               |
+---------------------+
| 2021-04-03 21:58:15 |
+---------------------+
1 row in set (0.00 sec)

Select the current datetime in UTC

SELECT CONVERT_TZ(NOW(), @@session.time_zone, '+00:00');
+--------------------------------------------------+
| CONVERT_TZ(NOW(), @@session.time_zone, '+00:00') |
+--------------------------------------------------+
| 2021-04-03 19:54:46                              |
+--------------------------------------------------+
1 row in set (0.01 sec)
SELECT UTC_TIMESTAMP();
+---------------------+
| UTC_TIMESTAMP()     |
+---------------------+
| 2021-04-03 19:55:19 |
+---------------------+
1 row in set (0.00 sec)

Get the current time zone delta from UTC

SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);
+--------------------------------+
| TIMEDIFF(NOW(), UTC_TIMESTAMP) |
+--------------------------------+
| 02:00:00                       |
+--------------------------------+
1 row in set (0.00 sec)

Get the current UNIX timestamp (in seconds)

SELECT UNIX_TIMESTAMP(NOW());
+-----------------------+
| UNIX_TIMESTAMP(NOW()) |
+-----------------------+
|            1622549495 |
+-----------------------+
1 row in set (0.00 sec)
SELECT UNIX_TIMESTAMP();
+------------------+
| UNIX_TIMESTAMP() |
+------------------+
|       1622549496 |
+------------------+
1 row in set (0.00 sec)

TIMESTAMP, DATETIME and time zone offsets

Before reviewing the differences between TIMESTAMP and DATETIME in-depth, let’s just remember that MySQL Server 8.0.19 introduced time zone offsets, which permit specifying dates in this format:

2019-12-11 10:40:30-05:00', '2003-04-14 03:30:00+10:00', and '2020-01-01 15:35:45+05:30'

Check release notes, the feature request, and the related worklog. I’ll share now a few details about storing and retrieving datetime and timestamp values.

TIMESTAMP facts

From the worklog description, we have:

  • TIMESTAMP with no offset is stored in UTC, hence converted to UTC from the current @@time_zone
  • TIMESTAMP with offset. The internal date/time value shall be adjusted to UTC by subtracting the time zone offset (but not @@time_zone) before being stored.
  • TIMESTAMP when read is converted to the corresponding connection’s @@time_zone

DATETIME facts

  • DATETIME with no offset is stored “as is”, and to be considered as stored in local @@time_zone.
  • DATETIME with offset. The internal date/time value shall be adjusted to UTC by subtracting the time zone offset and adjusting the date/time value to local time by adding the value of the session variable @@time_zone, before being stored.
  • DATETIME is read “as is” regardless of @@time_zone. It must be interpreted in relation to the context it was set (local @@time_zone), and the application must take that into account.

Examples

Using again this table definition:

CREATE TABLE mydate (
dt datetime DEFAULT NULL,
ts timestamp NULL DEFAULT NULL
) ENGINE=InnoDB;

With these time zone settings:

select @@system_time_zone, @@time_zone;
+--------------------+-------------+
| @@system_time_zone | @@time_zone |
+--------------------+-------------+
| EST                | EST         |
+--------------------+-------------+

Let’s insert some data:

INSERT INTO mydate(dt,ts) 
VALUES('2017-11-13 10:20:19+04:00', '2017-11-13 10:20:19+04:00');

INSERT INTO mydate(dt,ts) 
VALUES('2018-11-13 10:20:19', '2018-11-13 10:20:19');
SELECT * FROM mydate;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2017-11-13 01:20:19 | 2017-11-13 01:20:19 |
| 2018-11-13 10:20:19 | 2018-11-13 10:20:19 |
+---------------------+---------------------+

The first row has:

  1. the datetime with offset ‘2017-11-13 10:20:19+04:00′ is converted to UTC, hence ‘2017-11-13 06:20:19’ UTC
  2. UTC date time is then stored as local time (EST) applying @@time_zone, which is ‘-05:00:00’ (SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);)
  3. which takes us to local time ‘2017-11-13 01:20:19 EST. This will be stored, and will be returned whatever is the current @@time_zone
  4. the offset is not available anymore, once the datetime is stored. It must be the client to know that this was stored in EST. Often a convenient option would be storing in UTC, hence with @@time_zone=‘UTC’.
  5. the timestamp is converted to UTC, hence ‘2017-11-13 10:20:19+04:00’ becomes ‘2017-11-13 06:20:19’ by applying the offset, but not @@time_zone
  6. It is stored in its UTC form, then it is stored as ‘2017-11-13 06:20:19’ UTC
  7. when read, it is converted to local time zone @@time_zone (differently from date time, which is not converted but read “as is”), then applying the offset ‘-05:00:00’ (EST) it returns ‘2017-11-13 01:20:19’

Second row:

  1. date time is the local EST time, and stored “as is”, and is read “as is”. So it’s ‘2018-11-13 10:20:19’.
  2. timestamp is stored in the UTC form ‘2017-11-13 15:20:19’ (there is no offset, @@time_zone must be applied so there’s a conversion EST to UTC), but a read returns ‘2018-11-13 10:20:19’, because timestamps are converted to local time @@time_zone (EST)

Let’s play a bit:

mysql> SET time_zone=UTC;
Query OK, 0 rows affected (0.09 sec)
mysql> SELECT * FROM mydate;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2017-11-13 01:20:19 | 2017-11-13 06:20:19 |
| 2018-11-13 10:20:19 | 2018-11-13 15:20:19 |
+---------------------+---------------------+
2 rows in set (0.02 sec)

Does it make sense? It does, DATETIME is returned “as is”, regardless of @@time_zone, and timestamp is returned with no transformations (UTC is returned as @@time_zone, which is UTC, again). So it’s returned the way it was stored in the previous passage.

DATETIME and TIMESTAMP examples

When I first checked examples from docs, I admit I had to think for a second. But referring to rules summarized previously as “facts”, everything was clear and coherent. Let’s go through the example step by step. Let’s consider an EST system time zone.

SELECT @@system_time_zone;
+--------------------+
| @@system_time_zone |
+--------------------+
| EST                |
+--------------------+

That has the following shift from UTC:

SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);
+--------------------------------+
| TIMEDIFF(NOW(), UTC_TIMESTAMP) |
+--------------------------------+
| -05:00:00                      |
+--------------------------------+
1 row in set (0.00 sec)

Let’s then create tables to test both types:

CREATE TABLE ts (
id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
col TIMESTAMP NOT NULL
) AUTO_INCREMENT = 1;
CREATE TABLE dt (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
col DATETIME NOT NULL
) AUTO_INCREMENT = 1;

And let’s proceed to insert data into the DATETIME table:

SET @@time_zone = 'SYSTEM';
INSERT INTO dt (col) VALUES ('2020-01-01 10:10:10'), ('2020-01-01 10:10:10+05:30'), ('2020-01-01 10:10:10-08:00');
SET @@time_zone = '+00:00';
INSERT INTO dt (col) VALUES ('2020-01-01 10:10:10'), ('2020-01-01 10:10:10+05:30'), ('2020-01-01 10:10:10-08:00');
SET @@time_zone = 'SYSTEM';

This is what is returned from the DATETIME table:

mysql> SELECT id, col, UNIX_TIMESTAMP(col) FROM dt ORDER BY id;
+----+---------------------+---------------------+
| id | col                 | UNIX_TIMESTAMP(col) |
+----+---------------------+---------------------+
|  1 | 2020-01-01 10:10:10 |          1577891410 |
|  2 | 2019-12-31 23:40:10 |          1577853610 |
|  3 | 2020-01-01 13:10:10 |          1577902210 |
|  4 | 2020-01-01 10:10:10 |          1577891410 |
|  5 | 2020-01-01 04:40:10 |          1577871610 |
|  6 | 2020-01-01 18:10:10 |          1577920210 |
+----+---------------------+---------------------+
6 rows in set (0.00 sec)

Explanation (see previous DATETIME facts for the rules).

  1. ‘2020-01-01 10:10:10’ is EST, stored and read as such
  2. ‘2020-01-01 10:10:10+05:30’ is ‘2020-01-01 04:40:10’ UTC, which converted to EST is ‘2019-12-31 23:40:10’, stored and read as such
  3. ‘2020-01-01 10:10:10-08:00’ is ‘2020-01-01 18:10:10’ UTC, which converted to EST is ‘2020-01-01 13:10:10’, stored and read as such
  4. ‘2020-01-01 10:10:10’ is UTC, stored and read as such (@@time_zone has been set to ‘+00:00’)
  5. ‘2020-01-01 10:10:10+05:30′ is ‘2020-01-01 04:40:10’ UTC, stored and read as such (@@time_zone has been set to ‘+00:00’)
  6. ‘2020-01-01 10:10:10-08:00’ is ‘2020-01-01 18:10:10’ UTC, stored and read as such (@@time_zone has been set to ‘+00:00’)

Now let’s insert the TIMESTAMP table:

SET @@time_zone = 'SYSTEM';
INSERT INTO ts (col) VALUES ('2020-01-01 10:10:10'), ('2020-01-01 10:10:10+05:30'), ('2020-01-01 10:10:10-08:00');
SET @@time_zone = '+00:00';
INSERT INTO ts (col) VALUES ('2020-01-01 10:10:10'), ('2020-01-01 10:10:10+05:30'), ('2020-01-01 10:10:10-08:00');
SET @@time_zone = 'SYSTEM';

This is what is returned from the TIMESTAMP table:

mysql> SELECT id, col, UNIX_TIMESTAMP(col) FROM ts ORDER BY id;
+----+---------------------+---------------------+
| id | col                 | UNIX_TIMESTAMP(col) |
+----+---------------------+---------------------+
|  1 | 2020-01-01 10:10:10 |          1577891410 |
|  2 | 2019-12-31 23:40:10 |          1577853610 |
|  3 | 2020-01-01 13:10:10 |          1577902210 |
|  4 | 2020-01-01 05:10:10 |          1577873410 |
|  5 | 2019-12-31 23:40:10 |          1577853610 |
|  6 | 2020-01-01 13:10:10 |          1577902210 |
+----+---------------------+---------------------+
6 rows in set (0.00 sec)

Explanation (see previous TIMESTAMP facts for the rules).

  1. ‘2020-01-01 10:10:10’ is adjusted to UTC and stored as ‘2020-01-01 13:10:10’ but read as EST ‘2020-01-01 10:10:10’
  2. ‘2020-01-01 10:10:10+05:30’ is stored as ‘2020-01-01 04:40:10’ UTC, but read EST (UTC -05:00) as ‘2019-12-31 23:40:10’
  3. ‘2020-01-01 10:10:10-08:00’ is stored as ‘2020-01-01 18:10:10’ UTC but read EST (UTC -05:00) as ‘2020-01-01 13:10:10’
  4. ‘2020-01-01 10:10:10’ is already UTC, stored as such, and read ‘2020-01-01 05:10:10’
  5. ‘2020-01-01 10:10:10+05:30’ is stored as ‘2020-01-01 04:40:10’ UTC but read EST (UTC -05:00) as ‘2019-12-31 23:40:10’
  6. ‘2020-01-01 10:10:10-08:00’ is stored as ‘2020-01-01 18:10:10’ UTC but read EST (UTC -05:00) as ‘2020-01-01 13:10:10’

UNIX_TIMESTAMP example

Let’s see once more the use of offset to have unambiguous UTC strings. When an offset is specified, there is no calculation against @@time_zone: the literal is already expressed as UTC, it’s transformed into UTC with no offset for use/storage.

mysql> select @@time_zone;
+-------------+
| @@time_zone |
+-------------+
| EST         |
+-------------+
1 row in set (0.02 sec)
mysql> SELECT UNIX_TIMESTAMP('2015-11-13 10:20:19+01:00');
+---------------------------------------------+
| UNIX_TIMESTAMP('2015-11-13 10:20:19+01:00') |
+---------------------------------------------+
| 1447406419                                  |
+---------------------------------------------+
1 row in set (0.00 sec)

This is converting the timestamp with offset to ‘2015-11-13 09:20:19’ and returns seconds since ‘1970-01-01 00:00:00’ UTC. Let’s now change the @@time_zone.

mysql> SET time_zone='CET';
Query OK, 0 rows affected (0.01 sec)
mysql> SELECT UNIX_TIMESTAMP('2015-11-13 10:20:19');
+---------------------------------------+
| UNIX_TIMESTAMP('2015-11-13 10:20:19') |
+---------------------------------------+
| 1447406419                            |
+---------------------------------------+
1 row in set (0.00 sec)

The timestamp is in local @@time_zone, CET, which is UTC+1. So the seconds since ‘1970-01-01 00:00:00’ UTC is returned for ‘2015-11-13 09:20:19’.

Now, going local with UTC:

mysql> SET time_zone=UTC;
Query OK, 0 rows affected (0.09 sec)

The literal ‘2015-11-13 09:20:19’ does not need any transformation, it’s ready to be fed into UNIX_TIMESTAMP because it’s already UTC.

mysql> SELECT UNIX_TIMESTAMP('2015-11-13 09:20:19');
+---------------------------------------+
| UNIX_TIMESTAMP('2015-11-13 09:20:19') |
+---------------------------------------+
| 1447406419                            |
+---------------------------------------+
1 row in set (0.02 sec)

Takeaway points & recommendations

  • Set @@system_time_zone by setting TZ environment variable. It also can be specified using the --timezone option of the mysqld_safe
  • If time zone changes on the host (e.g. DST time zone change), server restart is required so it is reflected to @@system_time_zone
  • To set global @@time_zone, start the server with --default-time-zone
  • @@time_zone can be set per session
  • If @@time_zone is set to SYSTEM, every MySQL function call that requires a time zone calculation makes a system library call to determine the current system time zone. This call may be protected by a global mutex, resulting in contention.
  • Setting everything to UTC will bypass all problems about time zone confusion and DST ambiguity
  • An option to store DATETIME and avoid confusion would be storing date and time as DATETIME column and storing the time zone (like “America/Los_Angeles”) in another VARCHAR column.
  • CONVERT_TZ needs the original time_zone
  • DATETIME columns are not changed by the database time zone settings once stored. They will store and retrieve the same value every time, independently from the configured client time zone.
  • Check side cases when type conversion is performed in comparisons
  • Stay current with time zone changes
  • Use UTC comparisons to get rid of issues with leap seconds, check the docs
  • Beginning with MySQL 8.0.22, CAST() supports retrieval of a TIMESTAMP value as being in UTC, using the AT TIMEZONE operator.
  • As of MySQL 8.0.26, in addition to startup time initialization, if the server host time zone changes (for example, due to daylight saving time), system_time_zone reflects that change.
  • And what about replication? You should use the same system timezone (if hosts are configured differently, start the mysqld_safe with the proper --timezone or set TZ).

What about MDS?

And if you were wondering about time zone default settings for MySQL Database Service DB Systems, here they are!


mysql> SELECT @@system_time_zone,@@time_zone;
+--------------------+-------------+
| @@system_time_zone | @@time_zone |
+--------------------+-------------+
| UTC                | SYSTEM      |
+--------------------+-------------+
1 row in set (0.00 sec)

Conclusion

I have shared a few basic points to keep in mind when planning to store dates and times. I will write more in the future with an eye to clients (such as C/J time instants and recommendations). I hope this summary will be useful, and please comment to share suggestions, doubts and to report any side case you’re aware of. Thanks for reading!

3 thoughts on “MySQL Time Zone Support (with examples)

  1. Peter Brawley

    Useful summary, unfortunately grammatical problems pose reading challenges, copy needs editing.

    1. admin

      Thanks for reading, Peter. I have spotted a few issues in the text, and I’ve fixed them (there’ll surely be more!). Thanks for pointing out 🙂

  2. Jan

    Great explanation and examples, thank you very much!

Leave A Comment