than TAI and ask what is wrong with that approach. It is true that PTP has the capability of running a different timescale, what it calls the ARB (for ar- bitrary) timescale. This timescale could be any value that a user might desire, like the number of seconds since the last appearance of Halley's Comet. But it should be monotonic because running non-monotonic timescale can cause some serious issues to other applications outside of PTP. The main thing to consider is what would happen to the downstream systems when encountering timestamps that may go backward, repeat themselves, or just skip forward, as can happen to UTC time. You could even go further and implement a version of local time without using time zones, but this would cause chaos when summertime (daylight saving time) switchovers happen. One of the authors remembers this implementation option being used on large IT mainframe sys- tems that ran some form of local time. Because of that, all the machines would have to be taken down for a minimum of an hour on the autumn switch back from summer (daylight saving) to standard time. All of them had to be shut down before 3:00 a.m. (or whenever the switch back was scheduled), and the systems only restarted more than one hour later when the clocks again passed the time they were shut down. This action was necessary to stop applications crashing and databases becoming corrupted because time had flowed backward (imagine a transaction that started at 2:50 a.m. and finished at 2:05 a.m.). A similar process was necessary during the skip forward to summertime (daylight saving) to ensure that the elapsed time for transactions was correct, although it was not necessary to wait one hour. Other machines that needed to calculate elapsed times, such as telephone call logging, always used GMT/UTC SO that there were never any issues calculating the elapsed time for phone billing. This anecdote is given as an example only to illustrate that there are many disadvantages when us- ing a timescale that is not monotonic. The poin