View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006562 | Taler | wallet-core | public | 2020-09-03 14:30 | 2025-04-17 21:21 |
| Reporter | Florian Dold | Assigned To | Resolution deadline | ||
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Target Version | post-2.0 | ||||
| Summary | 0006562: should wallet-core handle major system clock changes gracefully? | ||||
| Description | The wallet should of course handle "going to sleep" for any amount of time gracefully. But what about something like the system time going from 2020->2022->2020? I.e. not just going forward, but also back in (system-)time. This might cause certain timeouts in the database (e.g. for re-fetching /keys or doing auto-refresh) to be way to far in the future. Do we expect the wallet to handle this? And if so, what's the best approach? (a) If any timestamp is *way* to far into the future, we automatically assume it's wrong and set it to "now()" in the database. The difficulty is" What's considered "too far in the future"? It might still break auto-refresh. (b) Instead of storing timestamps to point at an instant in the future, we store a "base" timestamp set to "now()" and a delta. If we ever encounter a base timestamp that is in the future, we assume the system time went backwards, and we need to reset this timestamp. | ||||
| Tags | No tags attached. | ||||
| Reading the subject, I was immediately thinking of (b). One issue with that is that we would have to update deltas whenever the base timestamp changes. A *better* solution: - store absolute times per operation for when retries are needed as we do now - additionally, store the "current time" (aka "last online"). If current time unexpectedly goes backwards, correct trigger-timestamps of pending operations by the negative delta. | |
| Makes sense, assigning back to myself to (eventually!) implement this. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-09-03 14:30 | Florian Dold | New Issue | |
| 2020-09-03 14:30 | Florian Dold | Status | new => assigned |
| 2020-09-03 14:30 | Florian Dold | Assigned To | => Christian Grothoff |
| 2020-09-03 14:52 | Christian Grothoff | Note Added: 0016820 | |
| 2020-09-03 15:13 | Florian Dold | Assigned To | Christian Grothoff => Florian Dold |
| 2020-09-03 15:13 | Florian Dold | Note Added: 0016821 | |
| 2023-02-17 01:36 | Florian Dold | Target Version | => 1.0 |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |
| 2023-12-22 13:22 | Christian Grothoff | Target Version | 1.0 => post-1.0 |
| 2024-08-12 08:12 | Christian Grothoff | Target Version | post-1.0 => post-2.0 |
| 2025-04-17 21:21 | Christian Grothoff | Assigned To | Florian Dold => |
| 2025-04-17 21:21 | Christian Grothoff | Status | assigned => acknowledged |