Note: By "Disable" daylight savings time, I mean for the system clock to ignore any time changes for daylight savings time (ie, if DST is disabled, then the clock will not "spring forward" an hour in March and will not "fall back" an hour in November.
I am designing an Qt application to run on Ubuntu 18.04 and I need to be able to set system timezone, time and date.
For settings time and date, I can easily use timedatctl to modify the system settings. However, this command does seem to be able to disable Daylight Savings Time. It does report whether DST is "Active" or not depending on the timezone and date, but you cannot disable/enable this settings.
On Windows, I had used tzutil.exe to setting DST enabled or not using the dst_off flag. Is there are any equivalent to Ubuntu?
I'll answer this question from a time zone perspective.
Disabling DST is generally not a good thing. Such features ignore the reality of time zones. Time zones are defined by individual governments around the world, and those same governments dictate where and when DST is in effect.
As an example, I'm located in Redmond, Washington, USA. By US law this is located in the Pacific Time zone, which is UTC-8 during standard time and UTC-7 during daylight time. US law currently allows states to opt-out of DST, which Arizona and Hawaii have done. But Washington has not, and thus DST is applicable for me here. Right now (in July) it is 11:00 PDT as I'm writing this. I cannot just decide for myself that its 10:00 PST. I would have to relocate to a different time zone to do that.
The time zones in the IANA time zone database (TZDB, Olson, etc.) which are used in most systems, including Ubuntu, define distinct areas around the world where local time has agreed since at least 1970. If there are areas that share the same standard time but differ in whether they get DST or not, or when DST applies, then they get their own distinct entry in the TZDB. In other words, there is no purpose in saying "I want to be in America/Los_Angeles without DST" because there is no place in the Pacific time zone that does that. If you're in the Pitcairn islands (UTC-8 without DST), then you simply use Pacific/Pitcairn.
Maybe a clearer example: Most of US Mountain Time uses MST (UTC-7) and MDT (UTC-6), which gets the TZDB identifier America/Denver. Arizona, most of which does not use daylight saving time, uses MST (UTC-7) all year, so it gets its own identifier of America/Phoenix in the TZDB.
Then you may ask, well why does Windows have a "Disable DST" feature? There are a few reasons I can talk publicly about (disclosure: I work at Microsoft, occasionally in this area).
The Windows time zone feature was originally created with Windows NT. At that time, the Olson database was around but was not as ubiquitous as it is today. Microsoft decided to create their own implementation, and thus to this day there are two different sources of time zones data. TZDB and Microsoft.
It used to be the case that the Windows time zone data did not cover the whole world. Thus, some Windows users had to rely on this feature to get accurate time. This changed dramatically with an update in June 2016 to align with Microsoft's mission statement of "... every person and every organization on the planet ...". Today, there is commitment and policy to ensuring accurate time zone data.
When a government decides to make changes to their time zone (enacting DST, suspending DST, changing DST dates or times, changing a standard time offset, etc.), occasionally the lawmakers make a crucial mistake of not providing enough lead time (see my blog post on this subject). When that happens, Microsoft may offer suggested temporary guidance on how to get the correct local time until an update can be provided. Such guidance may include disabling DST or switching to a different time zone. These recommendations are always temporary, thus it becomes debatable whether the feature needs to exist at all.
In general, most Windows users should never disable DST. If they find themselves needing to do that to get local time correct (outside of the rare case described above), they're probably just not setting their time zone to the correct entry in the first place.
TZDB time zones on Ubuntu and other OSs tend to have shorter update cycles than Windows, and thus are not impacted as heavily by short-notice changes.