PCI DSS v3.2, section 10.4 requires all critical assets to be synchronized for time, and recommends using one of the authoritative time sources such as ntp. That requirement, however, only begins to scratch the surface of what controls time in a computing environment.
There are several other aspects to time that need to be considered. In the simplest networked environment there are only two notions of time: the originating device and the final destination. But during credit card data processing there could be many other devices in the overall chain having different notions of time due to that processing crossing time zones, spanning Daylight Savings Time (DST) and non-DST observant regions, different transition dates between DST and non-DST in the differing regions, and operator settings on the card capturing device. There are also plenty of sources of contention when different systems disagree on what time it is due to so-called "drift".
Why does it matter? The standard requires all significant events to be auditable as to who performed them, and when. This is not just for administrative events, it could be for physical access, re-configuration of network controllers or firewalls, and turning on or off the audit trails themselves, amongst others. Does it ever matter to the cardholder? It might if the cardholder were attempting to repudiate a transaction, because their card was discovered missing at 13:50 and reported missing at 16:00, but a transaction occurred at 15:15.
Let us consider a web-based application taking cardholder data from the user's browser for a national business.
The user has their machine completely up to date for software patches and the clock was originally set manually to the pacific time zone with automated updates for daylight savings time. The user (and their computer) knows it is 14:00 PDT on March 19, 2015. The web form is being served by a computer in Chicago which knows it is 17:00 EDT. The payment processor is in Las Cruces, NM whose server knows it is 15:00 MT, but their storage system came from a site in New Jersey which is still set for EDT (because the disaster recovery process did not say to check or correct the time zone after relocation of the asset). To complicate the issue further, that storage system has a ten year-old version of the time zone database in which the transition between wintertime and DST was calculated using a different algorithm from the current year's mandate (It is using the first Sunday in April, rather than the current standard of the second Sunday in March). The cameras on the data center doors have no inherent notion of time and they rely on the data capture algorithm on their control device for their notion of time. No one since the original installation has looked at that. The logging algorithm for the card readers used to open the data center doors stores its data on the same storage device as the CHD transaction, but in a different partition.
What time is it?
As we've shown, each different part of the system has a different notion of the current time and there can be some very odd effects around the transition times for daylight savings.
http://www.iana.org/time-zones is the authoritative world-wide source for time zone definition files. Linux systems may not update the installed version of that database on a regular basis, which means you need a process to do so for every system in your CDE.
Software and embedded systems developers could do themselves a favor by automatically updating their release mechanisms to capture any changes to the time zone definition database regularly (preferably they would not distribute the time zone database at all, and declare in their release notes that they are relying on the underlying operating system to have the correct version).
To comply with PCI, systems administrators need to be aware of how each device, system, and application they track actually records the time at which any security-related event occurs. The easiest way to achieve this, is to set all devices within the CDE to use Universal Time Code (UTC) without attempting to give any time-based localization to any events, except within the user's browser or their application.
After a breach, forensics investigators will need to look at the entire chain of time settings to ensure they are looking at a consistent set of events.