Environment Time Zone

Introduction

In the past Engine Yard customers had a choice between running their instances and database servers with the default instance time zone or using using custom Chef cookbooks to change the time zone on the instances and database servers if needed.  The custom approach up until our stable-v5 stack has the problem that they run after our main cookbooks run, meaning that services that would need to know about the time zone would not be initially started with the correct time zone, often requiring awkward and/or painful service restarts.  Even with the advent of our integrated main/custom cookbooks runs in stable-v5 we feel that the need to change an environment's default time zone is common enough to warrant built-in support from our platform.

Overview

Beginning with stable-v4-2.0.124 and stable-v5-3.0.28 environment stack releases (not currently supported on our stable-v4 environment stack) you will see a new Time zone setting for when creating new environments as well as when editing existing environments while they are stopped:

Screenshot_2017-07-18_11.28.10.png

This setting allows you to set what time zone the instances and any PostgreSQL or MySQL database servers will run with.  The instances will initially boot with UTC but our Chef cookbooks will change that immediately and the database servers will then boot with the proper time zone configurations on their first boot.

Different Time Zones Settings for Different System Components

System (Instance) Time Zone

The OS's time zone configuration determines what is displayed by commands such as date and uptime as well as providing the time zone to use to applications that look to the OS for what to use.

Database Time Zone

The database's time zone configuration will affect values generated by functions like now(), current_time, and other date/time based functions and database components that are dependent on generating a current time value.

This determines what time zone will be set for client sessions that don't specify one for themselves.  While your Rails connections will be setting a time zone based on what is configured in config/application.rb any direct logins you make will not get that application setting.

PostgreSQL vs. MySQL

Note that PostgreSQL and MySQL handle the system and session time zones slightly differently.  MySQL has the system_time_zone configuration variable that takes its value from the OS when mysqld is started.  It's session variable time_zone then takes its value from system_time_zone if not set directly.  PostgreSQL does have an analog of MySQL's system_time_zone but does have the session timezone configuration variable that always defaults to GMT/UTC when not set directly.

So, for MySQL servers we will simply set the OS time zone as directed by this environment setting and let it take that as its system_time_zone value at startup such that all connections to the server will default to using that setting for their session time_zone value.  For PostgreSQL we take this environment setting value and use that for the timezone configuration value directly in postgresql.conf.

Application Time Zone

This setting will not affect or make any changes to your application's configured (or not) time zones.  Those will still need to be handled and managed in whatever way your application framework of choice required, e.g. setting config.time_zone in config/application.rb for Rails.

A note on the default time zone form value

The default time zone form value for new and existing environments is Instance Default / Custom.  That essentially means "do nothing" allowing the instance default -- UTC for new and recent instances but Pacific for some very old (5+ years) instances -- or any existing custom changes already made to stay in place.  If UTC is fine for your needs then you technically don't need to change the value from this to 'UTC', you can leave thins as-is with Instance Default / Custom.