It is usually not the database server which is vulnerable to error when an instant time leap occurs: its the applications that use the time that are.
There are generally two ways of tracking time: own time tracking or comparing system time. Both have some positive and negative tradeoffs.
Own time tracking
I see this used in some embedded programming and systems where exact timing is not that critical. In a main application loop a way of tracking a 'tick' is taken care of. This could be an alarm given by the kernel, sleep or select that gives an indication of the amount of time passed. When you know what time is passed you know you can add or subtract this time to a counter. This counter is what makes your timing application happen. For example, if the counter is higher than 10 seconds you can discard something, or you need to do something.
If the application does not keep track of time, the counter will not change. This could be desired depending on the design of your application. For example, keeping track on how long a long-running process is taking something is handled is easier with a counter than a list of start/stop timestamps.
- Not dependent on system clock
- Will not break on a big time skew
- No costly system call
- Small counters will cost less memory than a full timestamp
- Time is not very accurate
- Change in system time could make it even more inaccurate
- Timing is relative to running the application, does not persist
Comparing system time
This is the system used more often: store a timestamp and compare it with the timestamp using a system time call. Huge skews in the system time could threaten the integrity of your application, a task of a few seconds could take hours or end immediately depending on the direction of the clock.
- Accurate time comparison
- Persists over restarts and long outages
- Takes a system call to get a fresh timestamp to compare with other timestamps
- Application needs to be aware of skews or can break
Most of the applications will use timestamp comparing to schedule tasks. For database systems that could be cache cleanups.
All applications that use a database and call time functions in the query language will be affected by skews if the application does not detect and handle accordingly. Applications could never stop running or allow indefinite login periods depending on its purpose.
Mail systems will use timestamps and/or timeouts for handling stale or undelivered mails. A clock skew could affect that but with a much lesser impact. Back-off timers regarding reconnecting to servers could be missed resulting in penalties on the connecting server.
I do not think (have not researched) that kernel alarms will go off when changing the system time. Systems that use these could be safe.
Gently move time. This can be found in documentation of your favorite time solution.