As things get more complex with an immense amount of devices talking to each other depending and exchanging information, accurate time synchronization between devices is crucial.
When we started making terminal servers in the late 70’s, there was not even a real time clock to derive a time stamp to use when recording data.
As time progressed, logs and logging became more important, recording the information with some kind of crude time stamp was good enough. After all, it only mattered to the single unit that you were working on locally.
In later years, these files were being dumped into SYSLOG, the format of the time became more important. Then devices started dumping huge amounts of information into programs like Splunk where the date/time, time zones and daylight savings flags matter to build a better picture of what’s happening across your entire enterprise. With thousands of devices, all at different locations, getting the date/time, time zones and daylight saving flags consistent and synchronized becomes not only important, but required.
I have asked many people on how a unit should be initially setup, Local time or UTC (not to be confused or interchanged with GMT).
The answer was a little surprising. I would have thought that UTC would be a unanimous answer, but a lot of people chose local time. The over whelming answer to “why” was predictable. It was easier for the human at the location of the unit looking through the data to align the time zone of an event without having to do any conversion from UTC to local time. Directly clashing with letting machines compile and help you sort that immense amount of data from multiple sources.
I know that the machines can take all the different sources, from all the locations around the world and normalized them, but if a machine was not set with the correct time zone or the daylight savings profile is old, there could be skewed data ruining any collected data scattered across multiple locations.
Time may be an afterthought, but with your collection of data scattered across the globe, it may be worth taking a few minutes to solidify your event collection. Waiting until a problem occurs is a terrible time to realize any discrepancies.
With Cisco Live 2023 in Las Vegas coming up, I can’t wait to continue my research.