Timezone Troubles

Ideally, all systems would use the UTC timezone, and avoid problems with daylight savings shifts and timezone conversions. However, in practice, systems will use the local timezone, even if the company later follows the British Empire. Deployed systems will not migrate to UTC, as other projects will take priority, and the timezone change would require extensive testing and likely reveal previously unknown bugs. This article contains thoughts on better handling time related data, such as logfile entries or database records.

Technorati Tags: coding, Unix

Eliminate missing metadata: the Unix syslogd(8) daemon logs neither the year nor the timezone, among other syslogd problems. This drops vital information, and wastes time if multiple groups need to reconcile timestamps from multiple sources across different timezones. Always include the year and timezone with the timestamp, even if everything uses UTC. How would someone from a different company know records were in UTC without asking or making educated guesses?

Timezone names may cause problems: EST stands for both Eastern Standard Time (-0500), and Eastern Standard Time (+1000). Different systems across the world may default to one or the other offset, and may result in erroneous dates. The numeric offsets recommended by ISO 8601 will avoid this issue.

Different software products use a multitude of time formats. If possible, standardize on a single company wide time format. This format must include as much metadata as possible: milliseconds through the year, in addition to the timezone. Standardization promotes in-house utilities to convert and display timestamps, as only one or a handful of input formats need to be coded for. These utilities in turn would speed exchange of time related data between groups and systems using different timezones. Logs can be standardized via software libraries such as log4j, or by replacing the stock syslogd with syslog-ng.

Set timezone policies at hardware (BIOS), system (OS), and application level. The system and BIOS timezone must be configured automatically when deploying the system, for example in a KickStart configuration file, and enforced with configuration management software. Application software should be likewise maintained. However, users may restart or change the timezone on the fly, leading to unexpected problems. A system set to UTC will start a database in UTC. However, a user who sets TZ=US/Pacific under their shell may kill and restart the database via sudo(8). This will bring the database up in a different timezone, and may result in records with incorrect timestamps. Therefore, the application must be set in the application initialization script. While some users may remember to use sudo -H to clear their custom environment variables, most will not. Standard, documented initialization scripts will avoid the issue.

To recap:

• Always store fully qualified dates that include milliseconds, the year, the timezone.
• Avoid overloaded terms such as EST: use numeric offsets instead.
• Standardize on a short list of approved company time formats.
• Enforce timezone configuration at the hardware, system, and application level.

Finally, deploy time synchronization services to ensure all systems follow the same beat.