WorkingHours version: 2.16.2.0 Pro
OS + version: Windows 10
Device model: PC / Desktop
Description:
There seems to be an issue with how the app calculates the duration of a time entry during the transition to Daylight Saving Time (spring forward). When tracking time during the night of the time change, the skipped hour is not subtracted from the total duration.
For example, on the night of the DST change (e.g. March 29), working from 00:00 to 03:00 should result in exactly 2 hours of tracked time, because the clock jumps from 01:59 directly to 03:00. However, the app incorrectly calculates and logs 3 hours instead.
Steps to reproduce:
- Have a system timezone that observes DST (e.g., Central European Time).
- Track time or manually add a time entry on the date of the spring time change (e.g., March 29th) starting at 00:00.
- End the time entry at 03:00.
- Look at the calculated duration.
- Expected result: 2 hours.
- Actual result: 3 hours.
