It was said at the time that one advantage that the British forces had during the Falklands War was that they didn’t operate on local time (P or ‘Papa’), which was three hours behind standard UTC, but stayed on UK time, which was the same as UTC (Z or ‘Zulu’ time). Getting up three hours earlier gave them an edge in mounting operations which could catch Argentinian forces literally still napping.
This becomes still stranger when you consider why people switched to co-ordinated times in the first place. When travel and communications of any kind were slow, it didn’t matter that clocks set to local noon in London were fifteen minutes or so ahead of those in Bristol, as sending anything between the cities took days.
With the advent of Brunel’s Great Western Railway around 1841, its timetables had to use one consistent time throughout: Greenwich Mean Time (GMT), even though that was slightly out of kilter with local solar time in much of the rest of the UK. But around the globe, and particularly in countries which spread wide from east to west, simple humans couldn’t cope with clocks that ran divorced from the sun and daytime. So the world was divided up into time zones, and global time was shattered into forty different local times.
Computers have fudged around the problems of local and universal time ever since they were invented. Although they don’t have the irrational human dogma that the middle of the period of light should correspond to 1200 noon, computer users still expect to see the local time when they glance at the screen clock, or their sophisticated Apple Watch.
When computers record events which the user may wish to inspect later, there is a choice: they could record local time, or UTC. For older systems which are unlikely to travel far or often, it didn’t make much difference. All you needed to know was the current time zone, and simple arithmetic could convert one to the other. So long as times are consistently of one type, and you know which, there is never any confusion.
With mobile users, computers, and devices, time gets fraught. Suppose you have breakfast in London, and your MacBook Pro there downloads and installs an update at nine o’clock local time, or 0900 UTC. You then fly to Boston, and later that evening check the details of that update. Your watch is now showing Eastern Time, which is five hours behind London and UTC.
The simple, but unanswerable, question is whether your Mac should show the time of that update as 0900 UTC, or 0400 Eastern?
Your Mac should have no issues over this: as far as macOS is concerned, the time of installation of the update should have been 0900 UTC at the time, and 0900 UTC at any time into the future. But run a utility like LockRattler, and there’s a problem.
LockRattler could display all its times adjusted to the current time zone. So if you checked the update time when still in London, it would be reported as 0900. Later in the day when you are tucking into lobster in Boston, that time of installation would then be shown as 0400. So long as you remember that you were in London then, and the local time was actually 0900, there seems little harm in that.
But a month or two later, it would be a real puzzle. And when you’re at a conference on Hawaii and the installation is shown as taking place at 2300 on the day before, you will probably be baffled.
The alternative is to do what macOS internals do, and stick with UTC throughout. If you reversed the travel, and installed the update in Boston at 0900 Eastern, then it would be shown as 1400 UTC, but would stick at that no matter when or where you viewed it.
A third option, to display the time using whatever time zone was in use at that time, would only be feasible if such records included both the time and the time zone. Because computers don’t need to know the latter, as far as I know it is not directly recorded in any of the more important logs and records maintained by macOS.
If you can think of a better solution, given the limited information available, then try applying it to an app like Consolation, in which every log entry has a datestamp which includes the UTC time of that entry. Localising every one of those to the current time zone would be a not inconsiderable task, which could only confuse.
Maybe we should abandon time zones altogether, and all set out clocks and Apple Watches to UTC. Even then, I suppose there would still be some who would set their watches two or three hours earlier, to gain a tactical advantage.