On a CentOS 6.4 server, while system commands like date and hwclock show correct BST (British Summer Time), log files in /var/log/secure, /var/log/messages and others display timestamps in UTC (5 hours behind). This discrepancy affects core system logs but not application-specific logs.

# Current verification steps:
date                           # Shows BST
ls -l /etc/localtime           # Points to Europe/London
cat /etc/sysconfig/clock       # Confirms ZONE="Europe/London"
hwclock --show                 # Displays BST time

In CentOS/RHEL 6, the rsyslog service (or older syslog) defaults to UTC for timestamp generation regardless of system timezone settings. This explains why:

• System tools (date, hwclock) respect /etc/localtime
• Core system logs stick to UTC
• User-space applications may use either

Edit /etc/rsyslog.conf and add:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$RepeatedMsgReduction off
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$ActionFileEnableSync on
$ActionFileDefaultTimezone BST

Then restart:

service rsyslog restart

For persistent logging that survives daylight saving changes, configure timezone conversion in the log format:

$template LocalTimeFormat,"%timegenerated:1:10:date-rfc3339,local% %msg%\n"
$ActionFileDefaultTemplate LocalTimeFormat

After changes, test with:

logger "Timezone test message"
tail -n 1 /var/log/messages

If issues persist, check for:

• Custom logging rules in /etc/rsyslog.d/
• Journald interference (on newer systems)
• Hardware clock misconfiguration (hwclock --hctosys)

When modifying logging timezones:

• Log rotation compatibility
• SIEM system timestamp parsing
• Daylight saving time transitions
• Application-specific log handlers

For legacy systems where rsyslog modification isn't possible, consider using zdump in log processing scripts:

zdump -v /etc/localtime | grep 2013

---

On my CentOS 6.4 server, I've noticed a persistent discrepancy between system time and log timestamps. While date shows correct local time (BST), system logs like /var/log/secure record entries in what appears to be UTC:

# System time:
$ date
Thu May  9 13:39:04 BST 2013

# Log entry:
May  9 08:37:08 xxxx sshd[28612]: pam_unix(sshd:session): session opened for user root

Basic timezone settings appear correct:

$ cat /etc/sysconfig/clock 
ZONE="Europe/London"

$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 33 Apr  2 15:13 /etc/localtime -> /usr/share/zoneinfo/Europe/London

$ hwclock
Thu 09 May 2013 01:41:40 PM BST  -0.938110 seconds

The issue stems from how rsyslog (CentOS 6's default syslog daemon) handles timezones. Unlike applications that use system locale settings, rsyslog defaults to UTC for timestamping unless explicitly configured otherwise.

This explains why:

• System tools (date, hwclock) show BST
• Most system logs show UTC (5 hours behind BST)
• Some application logs (bfd, rkhunter) show correct time (they use system time directly)

Edit /etc/rsyslog.conf and add this directive:

$ModLoad immark
$ModLoad imuxsock

# Add this line:
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# For modern rsyslog versions (v7+):
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
template(name="LegacyFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg%\n")

Then restart rsyslog:

$ service rsyslog restart

For older rsyslog versions, you might need to rebuild with proper timezone support:

$ yum install rsyslog-devel
$ rpmbuild --rebuild --with localtime /path/to/rsyslog.src.rpm

After applying changes, test with logger:

$ logger "Timezone test message"
$ tail -n1 /var/log/messages

The timestamp should now match your system time.

For production systems, consider:

1. Upgrading to CentOS 7+ where this is better handled
2. Using centralized logging with proper timezone normalization
3. Implementing log rotation that preserves timezone settings