started counting at zero seconds from then. If you initialize a PTP grandmaster with no reference time in- put, it might send out timestamps counting from zero, and the slaves will think it is January 1970. Using this date and time means that PTP shares almost the same epoch as POSIX time. However, the POSIX timescale is different from the PTP timescale because POSIX is based on UTC ("sort of" recognizing leap seconds), yet PTP is based on TAI (and SO it is monotonic, with no leap seconds). This means that the POSIX epoch started 8 seconds after PTP because there were 8 leap seconds current at that time. Subtracting the then-current leap second value from a PTP timestamp and applying the POSIX time algorithm results in UTC. If you are writing some code or using a website to calculate time and notice a discrepancy any- where between 8 (1970) and 37 seconds (2020), you will know where to look for an explanation. See IEEE 1588-2008 section 7.2 and Annex B.2 for more information. The date/time of 1 January 1970 00:00:00 TAI was also almost exactly 31 December 1969 23:59:52 UTC. There was then an approximately 8-second difference between UTC and TAI, which in- creased to 10 leap seconds by the time the current leap second system was introduced on 1 January 1972. Therefore, the PTP timescale is always ahead of UTC by 10 seconds plus the number of leap seconds since 1972 (27 as of 2021), meaning 37 total seconds up until 31 December 2021 at least (IERS has announced that there is no leap second scheduled before this date). Note that as outlined in Chapter 3, the epoch used by GPS (like other GNSS systems) is different from both TAI and The PTP timestamp consists of two parts: secondsField: Seconds since the Epoch (6 bytes or a 48-bit unsigned integer) nanosecondsField: Number of nanoseconds following the second in the first part (4 bytes or a 32-bit unsigned integer) Expected values for the seconds timestamp, based on the PTP epoch, should be around 1,610,000,000 (Jan 2021) to 1,700,000,000 (Nov 2023), and these numbers