4

I'm aware of steady_clock and that it is the only clock that is specified to be monotonic. And I understand that system_clock can jump forward or backward due to daylight savings and leap years. But doesn't count() give you the number of ticks of the system clock since the Unix epoch, which is an always increasing number, regardless of how that integer number of ticks is parsed into a "calendar date + wall clock" interpretation? i.e. Even if the "calendar date + wall clock" jumps from 2am from 3am on a given day in March, hasn't the integer count of ticks only increased by one tick?

In short, doesn't it stand to reason that the value of std::chrono::system_clock.now().time_since_epoch().count() should be expected to, in the short term, increase monotonically (barring updates to the system clock, which of course are a very real event), even if the date+time it refers to jumps around?

EDIT

As pointed out by @SergeyA, if the system clock is changed, then of course the value will jump around. But I think the change in wall clock time due to daylight savings is not an NTP update event or a manual change by a user. If it helps clarify the question, I'm interested in uptimes of an hour or two, which could cross the DST boundary, as opposed to uptimes of weeks or months, in which the clock could drift.

user513951
  • 12,445
  • 7
  • 65
  • 82
  • If the time goes from 2am to 3am, and count is lets say seconds, how could it only increase by one? It is the count of seconds from 2am or 3am. – NathanOliver Jul 30 '19 at 18:34
  • But if the underlying representation of date+time is an integer number of seconds, then the number of seconds from 1970-01-01 00:00:00 to 2019-03-10 03:00:00 is only 1 + n, where n is the number of seconds from 1970-01-01 00:00:00 to 2019-03-19 01:59:59. – user513951 Jul 30 '19 at 18:39
  • Not a duplicate question, but it also answers this question: https://stackoverflow.com/questions/27365236 – Drew Dormann Jul 30 '19 at 18:41
  • 1
    The count doesn't change because of daylight savings or leap years. It changes because no clock keeps perfect time, and if you want your clock to stay accurate with respect to UTC, you have to occasionally adjust it. – Howard Hinnant Jul 30 '19 at 18:42

2 Answers2

2

Short answer - no, it does not. System clock can be (and will be in practice!) adjusted outside, as a result of manual action or source (NTP, PTP) synchronization.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • Oof, yes, you are right and I apologize, but I am going to edit my question to be more specific. I'm more interested in how the internal representation of time as ticks relates to wall clock time. – user513951 Jul 30 '19 at 18:44
  • @user513951 With your latest update, it kinda becomes XY problem. How do you know the clock won't change within an hour or two? On any rate, why are you committed to system_clock, when steady_clock was designed specifically around it? DST change itself doesn't change number of ticks, though. – SergeyA Jul 30 '19 at 18:46
  • Yes, there is an XY problem here, in that there is almost certainly another solution to the problem of "can objects timestamped on separate machines be sent to the same machine and be sorted by their creation time on the original computer." Since the accuracy of the sorting only matters to +/- 5 seconds, it seems to me that as long as the many machines are more-or-less synchronized using NTP, a uint timestamp relative to UNIX epoch should be good enough -- _unless_ the uint timestamp is jumping around due to things like DST. – user513951 Jul 30 '19 at 18:51
  • 1
    @user513951 I think, your latest update makes a problem much better defined one, and I am certain you could get a better answers with that description, rather than generic one. Timestamp is not expected to be jumping on DST. However, NTP is a primitive way of synchronization, I have seen clocks differ by more than a second in our networks unless machines were on PTP. – SergeyA Jul 30 '19 at 18:54
  • I did get enough information from this question to satisfy my curiosity about the underlying details, so I'll leave this in place, but per your suggestion [I've created a new question](https://stackoverflow.com/questions/57278471/whats-an-effective-way-to-sort-data-objects-by-creation-time-after-aggregating). Thanks! – user513951 Jul 30 '19 at 19:04
2

system_clock tracks Unix Time. Unix Time has no UTC offset adjustments (daylight saving). It is just a linear count of non-leap seconds. It is possible that an implementation could jump backwards during a leap second insertion. Though in practice the leap second is "smeared" with many tiny adjustments over a span of hours.

In theory it is possible for a system_clock to be monotonic. In practice, no clock keeps perfect time, and must be adjusted, (potentially backwards) to stay in sync with Unix Time.

In C++11/14/17, the Unix Time measure is not specified for system_clock, but it is the existing practice. In C++20, it will be specified.

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • I described the nature of my XY problem in a comment to SergeyA elsewhere, but I still think there's merit in the original question, and I think your answer gets to the bottom of what I was looking for. After reading this, I realize leap seconds was probably a red herring; I should have left them out, but I understand them better now thanks to this answer. Thanks! – user513951 Jul 30 '19 at 18:55