[krenel]

OP: Related stuff

How Golang[1] implements monotonic clocks — basically it retrieves always both wall and monotonic clocks on "time.Now()" and when doing operations of subtraction it uses the monotonic. When printing, it uses the wall time. Pretty neat. Details on the proposal by Russ Cox [2].

[1] https://golang.org/pkg/time/#hdr-Monotonic_Clocks [2] https://go.googlesource.com/proposal/+/master/design/12914-m...

[krenel]

In Python:

  import time 
  time.get_clock_info(name)

where name can be one of those:

  'monotonic': time.monotonic()
  'perf_counter': time.perf_counter()
  'process_time': time.process_time()
  'thread_time': time.thread_time()
  'time': time.time()

[vlovich123]

How does scheduling a timer to go off at 3pm this Saturday work?

[coder543]

That’s a hard question regardless of programming language. One commonly referenced YouTube video about time that explains why this is hard: https://youtu.be/-5wpm-gesOY

A reasonable first approximation of a solution would be to just check every second (or minute, or hour, depending on requirements) whether the current system time is later than the scheduled time for any pending events. Then you probably want to make sure events are marked as completed so they don’t fire again if the clock moves backwards.

Trying to predict how many seconds to sleep between now and 3pm on Saturday is a difficult task, but you can probably use a time library to do that if it’s important enough... but what happens when the government suddenly declares a sudden change to the time zone offset between now and then? The predictive solution would wake up at the wrong time.

[vlovich123]

No, you say "sleep until 3pm on saturday" you don't predict anything. The OS computes an exact value to wake up in when you arm. If that clock then jumps forwards or backwards or does anything weird you then recompute the expiry timeout for that timer. You can't do this in app-space but AFAIK all OSes provide a facility for you to do so.

https://developer.apple.com/documentation/dispatch/1420517-d... http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html

[krenel]

Well, the parameter of a Timer is of type Duration:

  A Duration represents the elapsed time between two instants as an int64 nanosecond count. The representation limits the largest representable duration to approximately 290 years.

Which is not really good because we have to calculate the time between now() and Saturday. If "wall time" changes, the scheduler will not be triggered when expected.

In that case I would not rely on Timer to use it in a cron-like fashion, or trigger a Ticker every second, check the _current_ wall time, and decide if anything needs to be done.

You can read more about Timers, Tickers and Sleeps in this (pretty interesting) article[1]

[1] https://blog.gopheracademy.com/advent-2016/go-timers/

[vlovich123]

Operating systems spend a lot of time designing APIs for you to deal with time correctly. The approach you've described is a limitation in Go, not inherent in general software development.

http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html https://developer.apple.com/documentation/dispatch/1420517-d...

OS timers when given a wall-clock expiry will do the right thing when the system wall-clock jumps.