- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
You are correct, a parameter group is the correct way to change the timezone. More information here: https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-change-timezone/
However, it’s a best practice to use the UTC time zone at the database layer. Because UTC doesn't observe daylight savings (DST), you don’t have to adjust the time later when it shifts. If you must use a local time zone, convert the time zone at the application layer instead. Before changing your time zone, consult your database administrator or application team.
Please also refer to this link for more information on changing the timezone setting: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html#Aurora.Overview.LocalTimeZone
After you set the local time zone, all new connections to the database reflect the change. In some cases, you might have open connections to your database when you change the local time zone. If so, you don't see the local time zone update until after you close the connection and open a new connection.
Hope it helps,
Jon
Relevanter Inhalt
AWS OFFICIALAktualisiert vor 4 Jahren- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
Hello Jon, I have changed it to US/Central and it is working as expected. Also it seems whenever daylight savings starts or ends, there should be no impact on the timezone because the value is US/Central and not anything related to UTC-06 or UTC-05 or CST or CDT. Whatever be the current time it will show that, after daylight savings starts or ends. What do you suggest?
I still suggest storing the data in UTC to avoid possible confusions and do the conversion at the app layer if possible.
It appears Postgresql uses the IANA/Olson timezone database to automatically apply daylight saving time at any given date and store this data in an internal table: https://www.postgresql.org/docs/current/view-pg-timezone-names.html. This means that a specific datetime may have two offsets. Please have a look at this documentation for more information: https://www.postgresql.org/docs/15/datatype-datetime.html#DATATYPE-TIMEZONES
Also please accept this answer if that helped you! Thanks