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.
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:
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
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
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
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/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.