The UNIX timestamp, since you get it from time () in PHP, is a kind of animal.
It took me a long time to figure this out, but it happens that the timestamp increases during the second jump, and when the second jump ends, the timestamp (but not UTC!) Jumps back one second.
This has some important implications:
- You can always accurately convert from UTC to UNIX timestamp
- You cannot always (for all time points) convert from a timestamp to UTC
- The Unix timestamp is non-contiguous, meaning it is indented. (Or, conversely, it remains unchanged without an increase for 2 seconds.)
- If you get a conversion with a conversion error from the UNIX timestamp to UTC, the error will be no more than 2 seconds. (This means that you may receive the wrong day.)
- In retrospect, the Unix timestamp appears linear. This means that if you save time series data and you are not interested in one or two seconds per year that are not displayed correctly, you can consider the saved time data adjacent.
Bypass
What if the Unix timestamp did not bounce suddenly and stay the same for 2 seconds? This is exactly what Google has done for its servers. Their solution was to slowly distort the time of only a millisecond at a time for a long period of time, to make the second shift jump almost invisible to applications, (As for applications and operating systems on Google servers, the jump seconds are no longer inserted by IERS . )
Prof. Falken
source share