5 ms·

This article makes the claim that the calculation of elapsed time is impacted by leap seconds, to the extent that the following value of “elapsed” may even be n

This article makes the claim that the calculation of elapsed time is impacted by leap seconds, to the extent that the following value of “elapsed” may even be negative: t0 = time.now() /* do stuff */ t1 = time.now() elapsed = t1 - t0 This is not correct. Leap seconds are only the concern of how to render time in a human readable way. System time itself always passes one second at a time, and calls to time.now() interspersed with sleep(1) will always go up by one second at a time. It’s just that at some times of year we render that as 23:59:60 and some times we don’t. But perhaps clock smearing is genuinely changing the way systems measure time, as opposed to smearing how the system renders t=1658818054.0 as hours, minutes and seconds? That seems implausibly incorrect. Lining up the minute hand with the noonday sun on one particular part of the planet should not possibly have any impact on measuring how long it takes to compile my code.

twic 4y ago
If your clock is perfectly synchronised to UTC, then this is not true. Two calls to time.now() one second apart will sometimes return the same value - the same count of seconds elapsed. Here's what POSIX has to say [1]: > 4.16 Seconds Since the Epoch > A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. > If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. > How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. > Note: > The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient. The key point to hang on to is that in POSIX "seconds since the epoch", a day is always 86400 seconds long, and midnight in GMT is always an exact multiple of 86400 - and so the value of "seconds since the epoch" must necessarily be bodged to account for leap seconds. It is not a monotonic, linear measurement of the passage of time. Another angle on this is to look at any date and time library you fancy. To convert from linear seconds-since-the-epoch time to a human-readable timestamp, they would have to obtain a leap second correction from somewhere, and apply it before doing formatting. There is no date and time library which does this. Because they all expect a nonlinear, UTC-aligned seconds-since-the-epoch. [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
Kuinox 4y ago
It depends of your library/language.

twic 4y ago

If your clock is perfectly synchronised to UTC, then this is not true. Two calls to time.now() one second apart will sometimes return the same value - the same count of seconds elapsed. Here's what POSIX has to say [1]: > 4.16 Seconds Since the Epoch > A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. > If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. > How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. > Note: > The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient. The key point to hang on to is that in POSIX "seconds since the epoch", a day is always 86400 seconds long, and midnight in GMT is always an exact multiple of 86400 - and so the value of "seconds since the epoch" must necessarily be bodged to account for leap seconds. It is not a monotonic, linear measurement of the passage of time. Another angle on this is to look at any date and time library you fancy. To convert from linear seconds-since-the-epoch time to a human-readable timestamp, they would have to obtain a leap second correction from somewhere, and apply it before doing formatting. There is no date and time library which does this. Because they all expect a nonlinear, UTC-aligned seconds-since-the-epoch. [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

Kuinox 4y ago

It depends of your library/language.