Our Amazon RDS MySQL instance currently uses a parameter group with `time_zone = 'US/Pacific'`. British Columbia is moving to a permanent UTC−7 offset, so the database would eventually apply an incorrect seasonal change if it continues using the `US/Pacific` timezone rules. I upgraded the MySQL engine to a version that supports the change, but the RDS DB parameter group does not accept `America/Vancouver`, apparently because the service does not expose the complete IANA timezone list. Moving the database to UTC and handling timezone conversion in the application would be the cleanest solution, but this is an inherited system and a larger application refactor is not currently feasible. Is there another supported way to configure the instance, such as a cluster parameter group or a different fixed-offset timezone, without setting the timezone on every connection?
2 Answers
RDS parameter groups do not expose every IANA timezone name, so `America/Vancouver` may simply be unavailable even if the MySQL engine supports it. A cluster parameter group would not necessarily solve that; the relevant setting depends on whether this is an RDS DB instance or an Aurora cluster. If the desired zone is not accepted, the practical database-side workaround is usually a fixed UTC−7 offset, provided the application and reporting logic can tolerate a fixed offset rather than a named timezone.
The long-term best practice is to store timestamps in UTC and apply the user or business timezone in the application. That avoids future timezone-rule changes and makes daylight-saving behavior explicit. Since a refactor is not realistic here, using a fixed offset or applying the timezone when connections are initialized may be the remaining options, but both should be tested carefully with existing stored values, scheduled jobs, and reporting.
This is the kind of problem that comes from treating local time as a permanent database setting. UTC in the database with offset handling in the application would avoid the regional timezone change entirely, although I understand why changing an old production system can require a lengthy approval process.
I would switch the system to UTC if I had control of the application, but this is an inherited project and that change is currently off the table.