Before you downvote, this question is not about time zone conversion - it is about best practices relating to time zone notation/use.
The question: in an environment or service where there is an option for generic Coordinated Universal Time (UTC) as well as several equivalent zones (e.g. "Dublin, Edinburgh, London (UTC+0)", "Monrovia, Reykjavik (UTC+0)"), does it make a difference from a development, scripting, monitoring, and administrative perspective to choose a specific time zone vs. the UTC generic option?
Phrased another way, has anyone run into issues when these were set differently (sometimes UTC generic, sometimes Reykjavik, sometimes London)?
For context I am working in Azure, but I would think this occurs on other server and cloud systems.
Perhaps this is a nothing item - but that is useful info to know as well.
Thank you!
Bergi is right. The differences between - Time Zones like UTC, London, and Reykjavik stem from the regional rules embedded in their respective time zone definitions, as maintained in tzdb. These differences can exist even if they currently have the same offset.
For example, Europe/London observes DST, i.e its offset alternates between UTC+0 and UTC+1 depending on the time of year. But Atlantic/Reykjavik does not observe DST, so its offset remains UTC+0 year-round. Basically, UTC is static and never observes DST or regional variations.
How to Handle This?
Always use UTC for system-level configurations to ensures there’s no ambiguity or risk from regional variations.
You can also checkout- tzinfo library