Dates, times and timezones are troublesome things.
Daylight saving, or “summer time” as it’s also commonly known, makes matters even worse, because many countries tweak their clocks twice a year in order to shift the apparent time of sunrise and sunset in relation to the regular working day.
In the UK, for instance, our clocks are set to Greenwich Mean Time when New Year comes round, but we wind them forward to GMT+1 at the end of March, and back to GMT again at the end of October.
Much of North America does something very, very similar, yet annoyingly different, setting the dates on which the clocks change to the start of November and the start of March instead. (Our two countries used to be conveniently aligned, but drifted apart slightly earlier this century.)
So our colleagues in Boston are always five hours behind us here in Oxfordshire, except for the brief period each autumn (or fall, given that we can’t even agree on the names of the seasons in our common language, let alone the alignment of our clocks) and spring when they aren’t.
Opponents of daylight savings dismiss it as a pointless complexity that we simply don’t need in the internet era, which is mildly ironic given that internet-era devices generally manager to adjust themselves automatically. Proponents of the system note that, for many people, shifting their working day to suit the season is no longer possible, because their days are ruled by the clock and not by the diurnal position of the sun, so shifting the clock to suit the season is the simplest alternative.
DST shifts considered harmful
Indeed, daylight saving timing trouble raised its head all this week when Chile decided to alter its customary clock-switch date temporarily (to add yet more complexity, the clock changes go the other way below the equator, because the seasons are reversed).
The temporary change was announced to avoid confusion on the day of the the country’s recent constitutional referendum.
The referendum took place on 04 September 2022, the day when clocks would normally go forwards for summer.
The clock change was therefore postponed for a week, lest people who forgot to reset their clocks before going to bed on Saturday night might misread the time on Sunday, and innocently end up arriving at their local voting station after it had closed, not realising they were an hour late because their clocks were an hour slow.
Even Microsoft felt the need to warn its users that Windows clocks, operating system timekeeping, meeting schedules and more might be thrown out of whack, given that the Chilean government didn’t announce this temporary change-to-the-change until last month, thus requiring a last-minute update to the Windows timezone database.
What if your clock is locked?
At least users of traditional operating systems can make temporary timezone adjustments themselves if needed.
Some devices are entirely dependent on firmware updates to display local time correctly.
For example, we have a miniature bicycle “computer” that we use as a compass and distance tracker when taking a journey (it’s amazing how fluidly and naturally you can navigate without ever looking at a map if you can keep track of time, distance and direction)…
…and although you can fiddle with all sorts of settings stored in the device, such as your body mass (apparently used in guessing your power output), map settings, location reference format, font size and more, the one thing you can’t do is set the date and time manually.
There simply isn’t a way to do it, at least for the builtin apps, and you can’t even tweak or hack those yourself, because the whole thing runs a digitally-signed, firmware-locked version of Linux
You can write your own add-on apps, and they can disply the date and time however they like, but they have to be compiled to run in a dedicated virtual machine inside a somewhat limited sandbox.
The theory is that if the device is working properly, it knows the absolute time via its GPS receiver, with an accuracy significantly better than the finest, largest, most expensive and most complex mechanical chronometers ever made.
It also knows where you are on the planet with an accuracy of well under 10 metres (you clearly tell which lane you were in, or see where you overtook buses, when you look back at a journey you recorded), so it can compute which physical timezone you’re in, and set the local time exactly, too.
Well, it can do that if its timezone database, showing the exact location of timezone boundaries, and the necessary displacements from UTC (the modern replacement for GMT on digital timepieces) are up-to-date.
Otherwise, you may have to add or subtract an hour in your head, if the device gets it wrong.
Or half an hour, because some regions use 30-minute timezones.
(It’s astonishing how many people refuse to accept that non-integer timezones exist, insisting that “all legal timezones go in hours”, which will be news to anyone in India or South Australia.)
Or 15 minutes.
(Try visiting Nepal or Eucla.)
Will banning daylight saving help?
Those who don’t like daylight savings, either because they think it’s an affront to the natural order of things, or because they can never remember to change the manually-operated clocks in their household, will assure us all that banning “summer time” will neatly solve all these issues.
But it won’t solve the problem of how to make sense of computer logs, and how to use them in IT troubleshooting, notably in cybersecurity threat response, where the sequence in which things happened can be very important indeed.
For example, if the logs show that crooks almost certainly got in at 03:30 on Tuesday evening, based on an exploit that was first abused at that time…
…did the new account creation timestamped 03:00 really happen before the exploit triggered, or could it have been afterwards?
Are the configuration changes timestamped 04:00 ones that need rolling back, because they happened after the attack started, or are they changes you need to keep because the logs are denominated in different timezones?
What to do?
There’s one thing you can do to help, both as a logfile creator and a logfile consumer.
Always reduce timestamps to UTC (universal co-ordinated time), thus factoring timezones out of your logfiles, and always record timestamps in a simple, unambiguous, alphabetically sortable format.
Simply put: consult, RFC 3339, and stick to Zulu time timestamps everwhere.
These look something like this:
2022-09-08T17:30:00.00000Z
The date always has four-digit years, so there’s no risk of reinventing the millennium bug.
Times don’t need AM and PM (computers can count to 24 at least as easily as you can count to 12), which removes ambiguity.
And that Z at the end denotes that the date and time shown have no timezone adjustment applied, so that any two Zulu time log entries can directly be compared to determine the sequence in which they took place.
Threat response is much easier, and much safer, when your timestamps are unambiguous, so we recommend this approach to everyone.
FURTHER READING ABOUT
THE IMPORTANCE OF CLARITY IN TIMESTAMP FORMATS
SOME LIGHT-HEARTED (YET GENUINE) REASONS FOR RFC 3339
