How do Linux logfiles handle daylight savings time? When you fall back not only would you get out of order values but also possibly duplicate values.
I'm thinking that I should set the system time to UTC and then process the logfiles into local timezone before handing off to a logfile viewer.
Logfiles are plain text files, and each line is appended at the end. So there is no loss of data when using non-UTC timezone.
Of course, you may view the files using a tool which can get confused. However, the usual reason for using UTC is to avoid ambiguity: you do not have to know what the local timezone is to interpret the data.
So yes, using UTC in logfiles is a good thing, and often done, but logfiles do not lose data if you do not do this.
Logfiles do not "handle" time zones, they just record what some application or service wrote there. So if an application writes "just the messages" and "directly to the log file", you're out of luck.
Some syslog servers (like syslog-ng) allow you to "decorate" the "raw" log data by time stamps, where you can choose to use UTC or local time with or without offset.
There are also logging programs available (e.g. logger), which can be used as an in-between for stdout logging and syslog services.
Log files can use a time format such as ISO 8601 or its cousin RFC 3339 that shows local time as an adjustment of UTC.
If the time entries end with Z or if it ends in a hyphen (8601), minus or plus followed by an offset value then it's using a format based on UTC.
When the log is based on UTC then daylight shows up as a change in the offset. The offset allows for local time and daylight to be indicated without ambiguity.
Subsequent entries can still have overlaps in time if the clock is adjusted.
As others have explained, it is in the nature of log files that one does not get out of order entries, no matter what happens to timestamps. The problem that you are envisaging is ambiguity, where a poorly chosen timestamp mechanism does not uniquely denote a single point in time.
This makes it hard for the poor system administrator reading logs to determine when things happened. After the fact, a log entry that (say) just has a timestamp of Apr 3 02:14:57 does not denote whether that's local time or UTC, nor (presuming for the sake of example that it is local time, and specifically Australian Eastern Time) whether it is 02:14:57 AEST or 02:14:57 AEDT.
But this is to unjustly presume that there's such a single thing as "Linux log files". Not all log files work the same way, and people have been moving away from this type of timestamp since the 1980s.
For example: Those of us who have been using daemontools and its ilk for many years have Linux log files that use TAI64N timestamps. A log entry looks like this:
@40000000577d024d2d10bb6d Hello there!
The long string of hexadecimal digits is a TAI64N timestamp. It's nothing more than a 64-bit count of seconds since a point in the very remote past (262 seconds before 1970-01-01 00:00:00 International Atomic Time) followed by a 32-bit count of nanoseconds.
TAI doesn't have different timezone variants. It doesn't even have repeated "leap" seconds. Every second has a unique fixed number.
And indeed, processing those timestamps into a human-readable local time is exactly the job of the tai64nlocal program:
jdebp % echo @40000000577d024d2d10bb6d Hello there\! | TZ=UTC0 tai64nlocal 2016-07-06 13:05:45.756071277 Hello there! jdebp % echo @40000000577d024d2d10bb6d Hello there\! | TZ=PST8PDT tai64nlocal 2016-07-06 06:05:45.756071277 Hello there! jdebp %
Timezones and DST changes have zero effect on my "Linux log files", and I can read the log files in any timezone that I want to. (I can also do things like merge sort multiple log files into one with sort's -m option.)
