Support

No, they cannot be the same. The log file name and its timestamps are always in UTC. There are several reasons for that. I will explain some of the major ones below. Before I do, I want to point out that you shouldn't care what the log filename is anyway. Go to Manage Backups, hover over the info icon and you can see its name.

Before I start, let me tell you why there's a timestamp. A backup output directory may be shared by multiple Akeeba Backup installations. There's a fairly common use case of many subdomains under the same user account, having a common, off-site backup output directory. This led to a clash of the log filenames, making it very confusing if not outright impossible to troubleshoot a failing backup. We needed a way to have relatively unique log filenames using just the information we already store in the database. Using the backup start timestamp in the log filename does that since it's unlikely that all sites sharing the same output directory will start a backup at the exact same second (that would cause a massive CPU and I/O spike on the server, so people with this use case temporally stagger their backup starts). That's really the only reason there's a timestamp on the filename.

Now let's move on to why we're using the timestamp in UTC.

Remember that the log file needs to be written to before calculating the backup filename. Depending on the server the "before" might be a few milliseconds up to several seconds. Therefore the two names are very likely to not match. This would be perpetually reported as a bug. Doing the backup filename calculation when opening a backup profile, before reading the backup profile information, before validating them and the state of the backup engine, would be a completely idiotic thing to do. At the very least it would require always using the same backup output directory and backup filename format which is a major security concern (incidentally, that's exactly what most WordPress backup plugins do and they do indeed suffer from that security concern — that's something I had already addressed in 2006, a couple of months after the very first version of JoomlaPack, Akeeba Backup's predecessor).

Further to that, the backup filename may or may not have a timestamp depending on your backup profile settings. Therefore there's no guarantee about a "match" between the backup filename and the log filename.

Also remember that the backup filename's timestamp may be in UTC or it may follow Joomla's timezone and it may or may not include the timezone in it, all depending on your component and backup profile settings. Joomla's timezone may be one which changes for summer and standard time. You may change Joomla's timezone after a backup has been taken. Why's that a problem? It means that you don't know the timezone the backup filename was using. The Manage Backups, View Log and ALICE pages as well as the quota management need to be able to figure out with 100% precision the log filename of any given backup record given its start timestamp, numeric ID and tag — that's the information stored at the end of the very first backup step, before the backup output filename is calculated. If we can't be sure which timezone was used in the filename you'll end up with plenty more and far more important issues.

If you are taking hourly backups or backups which run at the timezone change point of time this can become problematic. Remember that going from DST to standard time the clocks move backwards. In Cyprus and Greece this happens at 00:00 UTC. This means that at 03:00 EEST clocks move back to 02:00 EET. This means that a log entry would show 02:59:59 and the next entry after it would show 02:00:01. This did confuse people and for several years we had several people file a bug twice a year when the clocks changed. In Spring they were complaining that a step that should be instantaneous took over an hour. In Autumn they were complaining that the log said they were moving back in time. The same thing would happen with log files.

There are few more less important considerations but I am trying to keep this not too long.

Don't assume that I didn't think of any of that and I didn't weigh the pros and cons. Every decision I made in how the backup engine works has dozens to hundreds of non-obvious considerations, many of them inter-related and leading to mutually exclusive solutions. The reason I am doing end user support is to have a firm grip on the use cases which is of paramount importance in deciding which of the mutually exclusive solutions would work best for the majority of our target audience.