How to test DST when using NTP

We have long-running processes on a server. The server clock is synced with NTP. And RTC is set to UTC. Localtime is set to current DST timezone:

$ timedatectl       
               Local time: Thu 2021-12-02 08:41:01 CET
           Universal time: Thu 2021-12-02 07:41:01 UTC
                 RTC time: Thu 2021-12-02 07:41:01
                Time zone: Europe/Budapest (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

We want to test what will happen at the next DST change. (Do we need to restart the application, or not).

How do i simulate such a change? Setting the date to a totally fake value is not an option (i think) since we are using NTP.

The simplest answer would be to turn off NTP. Then change your clock, do the test, and afterwards turn NTP back on again. If it's acceptable that the test might fail, and if it's acceptable that the application sees a DST changeover even though no DST changeover actually happened, then it should also be acceptable that NTP is turned off for a brief moment.

If you don't have a second server to test things on – there's a faketime tool which can be used to make a process start with a different clock value. You can't use it to make already running processes time-travel, but you could stop a service; start it via faketime; do the test; and later restart the service normally.

In most cases, literally nothing will happen at the next DST change.

NTP always delivers UTC time. You don't ask NTP servers for "Budapest time", (and you don't have "European" or "American" NTP servers which would switch to DST on different months,) instead you always get the same UTC time from every server.

^{(There may be specialized NTP servers that deliver UT1 or TAI, but those are also global and not timezone-based.)}

The Linux kernel clock always runs on UTC time (no matter what mode you use for the RTC). It is not adjusted for DST. When apps get the current time from the kernel, they always get UTC (in "Unix epoch"), and they only convert timestamps to local time when they need to. The same goes for Windows, BSDs, etc.

Most applications use the 'tzdata' timezone database, which contains a list of date ranges with their offsets. Your timezone isn't just set to a fixed "+0100" or "+0200" offset – it is set to "Europe/Budapest", and the same /usr/share/zoneinfo/Europe/Budapest tzdata file allows applications to convert any timestamp to local time, automatically using DST or non-DST rules as needed. (Use zdump -v Europe/Budapest to see its contents.)

So typically the only time you might need to restart applications is if the 'tzdata' database gets updated, e.g. if your region suddenly decides to play by different DST rules. Some programs will automatically re-read the tzinfo file if it's changed, others might not.

(Yes, you'd need to restart some apps if the kernel clock jumps back – but as the kernel clock is not affected by DST adjustments, the only time it'd jump back is if it got an incorrect time from the RTC during boot, e.g. if it was a few hours too fast. Your NTP client tries to avoid jumps during normal operation, but it may do one when the system boots up and syncs for the first time.)