Bug: Incorrect duration calculation during Daylight Saving Time (DST) transitio

MartinF

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.

timo

WorkingHours does not take time zones into consideration at all. It is not stored in the database or considered in the calculations. This is currently expected behaivor. There is a feature request about this here: Ignore or include timezone in calculation of hours

MartinF

Hello Timo,

Thank you for the quick reply. I respectfully disagree that this is 'expected behavior' and 'no bug' (the resolution of this report), and I would love to briefly clarify why.

I completely understand that implementing full timezone support (like handling travel between timezones or syncing different zones across devices, as mentioned in the linked feature request) is a massive task that would require database changes. I am not asking for that.

My report is strictly about the local Daylight Saving Time (DST) transition on a single device. This specific issue can actually be fixed without any database changes and without storing timezones.

Since the OS is already aware of the local DST rules, the app could simply calculate the duration by temporarily converting the local Start and End times to UTC just for the math. For example: (EndTime in UTC) - (StartTime in UTC).

This simple local calculation would correctly output 2 hours instead of 3 for that specific night, without the app ever needing to store timezone data or care about global timezones.

I really love WorkingHours and rely on its accuracy for my daily work. I hope you might reconsider this specific edge case, as it silently falsifies the tracked time for anyone working night shifts twice a year.

Thanks for your hard work on the app!

timo

If the app reads the database at 4:00 and sees that the timer was started at 2:30 - how should it know if it was started before or after the 3:00 -> 2:00 flip? Should it now show 1:30h elapsed duration or 2:30h?

MartinF

Hi Timo,

I understand your concern regarding the ambiguous hour in autumn (fall back) and not wanting to change the database schema. However, this can be solved without touching the database at all.

Here is why a full database timezone implementation isn't necessary for these specific cases:

The autumn case (local state, no DB changes):
If a timer is actively running during the autumn transition, the app doesn't need to store a UTC offset in the main database. It can simply save a temporary flag (like isFirstOccurrence or a temporary UTC start time) in the local app cache/preferences just for that active session. Once the timer is stopped, the app calculates the correct duration and saves only the final duration to the database, just like it always does.

The spring case (unambiguous math):
As mentioned in my initial report, the spring transition (spring forward) has no ambiguous overlap. The hour from 02:00 to 02:59 simply does not exist. If an entry is logged on that day, applying a local UTC conversion strictly for the math (EndTime UTC - StartTime UTC) resolves the 1-hour error immediately.

The absolute minimum (user warning):
If implementing the logic above is still out of scope right now, the absolute minimum for a professional productivity tool should be a warning. If an entry overlaps with a DST transition day, the app should show a prompt (e.g., "Note: This entry falls on a time change date. Please verify the duration manually.").

Silently logging incorrect durations and falsifying tracked work hours is the worst possible outcome for a time-tracking app. I highly recommend at least implementing the spring fix and a warning for the autumn case to prevent silent data corruption for your users.

Thanks

timo

MartinF . It can simply save a temporary flag (like isFirstOccurrence or a temporary UTC start time) in the local app cache/preferences just for that active session

This flag would not sync to another device (because only the database is synced) and then the other device would show a different duration for the timer than the device on which the timer was started.

MartinF If an entry is logged on that day, applying a local UTC conversion strictly for the math (EndTime UTC - StartTime UTC) resolves the 1-hour error immediately.

UTC doesn't have DST and therefore no adjustment on the time is done if UTC timestamps are subtracted from each other. I would have to calculate the duration given a certain non-UTC time zone and that would increase complexity. . As I wrote earlier, WorkingHours doesn't know timezones and I don't want to change this.
The "two devices show different durations" problem might also happen if different timezones are used

MartinF If implementing the logic above is still out of scope right now, the absolute minimum for a professional productivity tool should be a warning. If an entry overlaps with a DST transition day, the app should show a prompt (e.g., "Note: This entry falls on a time change date. Please verify the duration manually.").

I will consider this

MartinF

UTC doesn't have DST and therefore no adjustment on the time is done if UTC timestamps are subtracted from each other. I

I mean that you can calculate it with the current device's time in UTC. I explained this earlier. The device (i.e. Windows PC) should be assumed to 'know' the time.