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
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!
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