# Any side-effects/implications of changing time\_zone config in MySQL from SYSTEM to +00:00?

**URL:** <https://forums.percona.com/t/any-side-effects-implications-of-changing-time-zone-config-in-mysql-from-system-to-00-00/9454>\
**Category:** Percona Server for MySQL 8.0\
**Created:** [February 26, 2021, 8:23pm UTC](https://forums.percona.com/t/any-side-effects-implications-of-changing-time-zone-config-in-mysql-from-system-to-00-00/9454 "2021-02-26T20:23:45Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vamsi\_P](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vamsi_p/32/2549_2.png) [@Vamsi\_P](https://forums.percona.com/u/Vamsi_P)\
**Post date:** [February 26, 2021, 8:23pm UTC](https://forums.percona.com/t/any-side-effects-implications-of-changing-time-zone-config-in-mysql-from-system-to-00-00/9454/1 "2021-02-26T20:23:45Z")

</div>

Hi Folks,

We have a date time column defined as datetime(6) NOT NULL DEFAULT CURRENT\_TIMESTAMP(6) ON UPDATE CURRENT\_TIMESTAMP(6).

We use UTC on our machines. We found that changing the value of @@session.time\_zone from SYSTEM to +00:00 reduced kernel calls and gave better performance in use cases that do lot of inserts/updates.

In both cases (ie +00:00 or SYSTEM) it should be using UTC time zone, right? Are there any side-effects/implications of changing the value from SYSTEM to +00:00 that I need to be aware of?

We are thinking of changing @@global.time\_zone as well to +00:00.

Thanks,  
Vamsi

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [February 26, 2021, 9:24pm UTC](https://forums.percona.com/t/any-side-effects-implications-of-changing-time-zone-config-in-mysql-from-system-to-00-00/9454/2 "2021-02-26T21:24:46Z")

</div>

Hello @Vamsi_P,  
If your system/OS timezone is currently UTC, changing MySQL to +00:00 should be the same thing as UTC. Very interesting that this saves resources. I guess because using SYSTEM causes MySQL to make a request to the OS vs just calculating itself.

---

<div class="post-metadata">

**Author:** ![Vamsi\_P](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vamsi_p/32/2549_2.png) [@Vamsi\_P](https://forums.percona.com/u/Vamsi_P)\
**Post date:** [March 15, 2021, 4:35pm UTC](https://forums.percona.com/t/any-side-effects-implications-of-changing-time-zone-config-in-mysql-from-system-to-00-00/9454/3 "2021-03-15T16:35:02Z")

</div>

ok, thank you!  
Vamsi

---

<div class="post-metadata">

**Author:** ![marcos.albe](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/marcos.albe/32/904_2.png) [@marcos.albe](https://forums.percona.com/u/marcos.albe)\
**Post date:** [March 15, 2022, 12:20am UTC](https://forums.percona.com/t/any-side-effects-implications-of-changing-time-zone-config-in-mysql-from-system-to-00-00/9454/4 "2022-03-15T00:20:36Z")

</div>

I know I’m late to the party, but this forum topic was third in a google search for mysql time zone system calls; The issue is possibly related to [1244585 – Reduce lock contention in \_\_tz\_convert()](https://bugzilla.redhat.com/show_bug.cgi?id=1244585)  
There was a good article here [MySQL time\_zone and CPU Spike another performance troubleshooting](https://mydbops.wordpress.com/2022/02/17/mysql-time_zone-and-cpu-spike-another-performance-troubleshooting/)