| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This still gives us more than 8000 years of range, and uses a tiny bit
less CPU time.
|
| |
|
|
|
|
| |
Sleep a millisecond if otherwise an update would get skipped. This
happens if a refresh is requested in the last millisecond before the
next synchronized update is expected.
|
| |
|
|
| |
It's now optional again, but needs its own block.
|
| |
|
|
|
|
|
| |
Either it's updating every n seconds (float) but not synchronized to the
actual UTC time, or it's updating synchronized, but with the limitation
that the update rate is given as updates/(30 minutes). Explanation why
this format was chosen is in the source file.
|
| |
|
|
|
|
|
| |
If the clock is started 1 ms before the configured time interval, it
currently will skip one update. Because waiting times up to 30 minutes
are planned to be supported, this can cause the clock to be quite wrong
for quite some time...
|
| | |
|
| | |
|
| |
|
